Packaging:EclipsePlugins

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Update to latest approved draft)
Line 6: Line 6:
  
 
== Glossary ==
 
== Glossary ==
* '''Plugin<sub>1</sub>''': A functional unit of Eclipse functionality.  Post-Eclipse 3.0, the term "plugin" can almost always be interchanged with the term "bundle" which itself is shorthand for "OSGi bundle".
+
* '''Bundle''': An [http://en.wikipedia.org/wiki/OSGi#Bundles "OSGi bundle"].
* '''Plugin<sub>2</sub>''': The colloquial name given to a set of functional Eclipse plugins ex. "CDT".  More common usage among non-Eclipse developers than the above definition.
+
* '''Plugin''': A functional unit of Eclipse functionality.  Post-Eclipse 3.0, the term "plugin" can almost always be interchanged with the term "bundle". Colloquially, among non-Eclipse developers, the term is used to refer to a set of functional Eclipse plugins ex. "CDT".
* '''Feature''': A collection of plugin<sub>1</sub>s.
+
* '''Feature''': A collection of plugins.
 
* '''Fragment''': A bundle with native elements ex. <code>org.eclipse.core.filesystem.linux.${arch}</code>
 
* '''Fragment''': A bundle with native elements ex. <code>org.eclipse.core.filesystem.linux.${arch}</code>
  
Line 37: Line 37:
  
 
=== pdebuild ===
 
=== pdebuild ===
As of Fedora 9, there is a script that makes invoking PDE Build easy:  <code>/usr/lib{,64}/eclipse/buildscripts/pdebuild</code> (in Fedora 9 the script is located at <code>/usr/share/eclipse/buildscripts/pdebuild</code>):
+
There is a script that makes invoking PDE Build easy:  <code>/usr/lib{,64}/eclipse/buildscripts/pdebuild</code>:
  
 
<pre>
 
<pre>
Line 56: Line 56:
 
</pre>
 
</pre>
  
{{Template:Warning}} Note: PDE Build must be called explicitly in Fedora 8 and earlier (including EPEL 5)The following snippet may be used to replace the <code>pdebuild</code> call in the template:
+
== File Locations ==
 +
All platform-independent plugins/features should go into <code>%{_datadir}/eclipse/dropins/<one word name of this feature or plugin></code>.  JARs should therefore go into <code>%{_datadir}/eclipse/dropins/<name>/plugins</code> and features should go into <code>%{_datadir}/eclipse/dropins/<name>/features</code>. Architecture-specific plugins/features should go into <code>%{_libdir}/eclipse/dropins/<one word name of this feature or plugin></code>JARs should therefore go into <code>%{_libdir}/eclipse/dropins/<name>/plugins</code> and features should go into <code>%{_datadir}/eclipse/dropins/<name>/features</code>.  Example:
  
 
<pre>
 
<pre>
/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} <other dependencies ex. cdt>
+
%install
mkdir home
+
installDir=%{buildroot}%{_datadir}/eclipse/dropins/quickrex
SDK=$(cd SDK > /dev/null && pwd)
+
install -d -m 755 $installDir
 +
unzip -q -d $installDir \
 +
build/rpmBuild/de.babe.eclipse.plugins.QuickREx.zip
 +
</pre>
  
homedir=$(cd home > /dev/null && pwd)
+
== Arch vs. noarch ==
 +
While many Eclipse plugins will be architecture-independent, there will be some that contain native parts. Plugins without native fragments should be noarch and go into %{_datadir}/eclipse/dropins and plugins with native fragments should be arch-dependent and go into %{_libdir}/eclipse/dropins.
  
java -cp $SDK/startup.jar                              \
+
== Running the Reconciler ==
-Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration  \
+
Starting with Fedora 17 all Eclipse plugin and feature RPMS must run the reconciler after installation.
org.eclipse.core.launcher.Main                    \
+
-application org.eclipse.ant.core.antRunner      \
+
-Dtype=feature                                    \
+
-Did=org.eclipse.plugin_feature                  \
+
-DbaseLocation=$SDK                              \
+
-DsourceDirectory=$(pwd)                          \
+
-DbuildDirectory=$(pwd)/build                    \
+
-Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \
+
<additional build arguments ex. -DjavacSource=1.5>
+
-f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml \
+
-vmargs -Duser.home=$homedir                      \
+
<additional VM arguments ex. -DJ2SE-1.5=%{_jvmdir}/java/jre/lib/rt.jar>
+
</pre>
+
  
==== EPEL 5 ====
+
To add support for this in your packages you have to create <code>%post, %postun</code> and <code>%posttrans</code> sections.
The <code>copy-platform</code> script is in a different location on RHEL 5 than it is in Fedora.  If calling <code>copy-platform</code> explicitly, the following snippet may be useful to facilitate building Eclipse plugins for EPEL 5:
+
and add the eclipse macros as follows:
 
<pre>
 
<pre>
%if 0%{?rhel} == 5
+
BuildRequires:    eclipse-platform
/bin/sh -x %{_libdir}/eclipse/buildscripts/copy-platform SDK %{eclipse_base}
+
 
%else
+
%package [subpackage name]
/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base}
+
...
%endif
+
Requires(post): eclipse-platform >= 1:3.7.1-15
 +
Requires(postun): eclipse-platform >= 1:3.7.1-15
 +
 
 +
%post [subpackage name]
 +
%_eclipse_pkg_post
 +
 
 +
%postun [subpackage name]
 +
%_eclipse_pkg_postun
 +
 
 +
%posttrans [subpackage name]
 +
%_eclipse_pkg_posttrans
 
</pre>
 
</pre>
  
== File Locations ==
+
As you will have noticed in the example above you also need to add post and postun requirements on eclipse-platform to your packages' package section in the specfile. In addition you must make sure that you have a direct or indirect build requirement on eclipse-platform >= 1:3.7.1-15.
All platform-independent plugins/features should go into <code>%{_datadir}/eclipse/dropins/<one word name of this feature or plugin></code>.  JARs should therefore go into <code>%{_datadir}/eclipse/dropins/<name>/plugins</code> and features should go into <code>%{_datadir}/eclipse/dropins/<name>/features</code>. Architecture-specific plugins/features should go into <code>%{_libdir}/eclipse/dropins/<one word name of this feature or plugin></code>. JARs should therefore go into <code>%{_libdir}/eclipse/dropins/<name>/plugins</code> and features should go into <code>%{_datadir}/eclipse/dropins/<name>/features</code>.  Example:
+
  
 +
At this point you will be done, but if you want the details please keep reading. RPM places all the plugin artifacts in the proper directories. However that does not update the eclipse metadata. This means that until the next time eclipse starts it is unaware of the newly installed plugins. Because the user would normally run eclipse not as root Eclipse does not have permission to write to the meta data files located in the installation directory. It therefore creates a parallel version in the user's home directory <code>~/.eclipse</code>. This creates a fragile installation and leads to a whole host of problems. To avoid this we run the Eclipse reconciler during rpm installation. The eclipse reconciler is an Eclipse application which goes through checks the installation directories and updates the eclipse metadata with any newly installed plugins.
 +
 +
Here is an example from the eclipse-emf spec file for the eclipse-rse-sdk rpm:
 
<pre>
 
<pre>
%install
+
BuildRequires:    eclipse-platform >= 1:3.7.1-15
rm -rf %{buildroot}
+
 
installDir=%{buildroot}%{_datadir}/eclipse/dropins/quickrex
+
%package sdk
install -d -m 755 $installDir
+
[...]
unzip -q -d $installDir \
+
Requires(post): eclipse-platform >= 1:3.7.1-15
build/rpmBuild/de.babe.eclipse.plugins.QuickREx.zip
+
Requires(postun): eclipse-platform >= 1:3.7.1-15
 +
 
 +
%post sdk
 +
%_eclipse_pkg_post
 +
 
 +
%postun sdk
 +
%_eclipse_pkg_postun
 +
 
 +
%posttrans sdk
 +
%_eclipse_pkg_posttrans
 
</pre>
 
</pre>
  
For Fedora 9, all plugin jars should go into <code>%{_datadir}/eclipse/plugins</code> and features should go into <code>%{_datadir}/eclipse/features</code>.  The only exception is for fragments which should go into <code>%{_libdir}/eclipse/plugins</code> (and <code>features</code> if applicable). Note that this is not reflected in the template below.
+
The above macros expand to the following:
 +
<pre>
 +
%package sdk
 +
[...]
  
== Arch vs. noarch ==
+
Requires(post): eclipse-platform >= 1:3.7.1-15
While many Eclipse plugins will be architecture-independent, please follow the ["Packaging/GCJGuidelines"]  with regards to <code>gcj</code> ahead-of-time compilation. As those guidelines specify, <code>gcj</code>-compiled packages are arch-dependent and are thus not <code>noarch</code>.
+
Requires(postun): eclipse-platform >= 1:3.7.1-15
 +
 
 +
%post sdk
 +
touch /var/run/eclipse/run-reconciler
 +
 
 +
%postun sdk
 +
touch /var/run/eclipse/run-reconciler
 +
 
 +
if [ $1 == 0 ]; then
 +
  eclipse-reconciler.sh
 +
fi
 +
 
 +
%posttrans sdk
 +
eclipse-reconciler.sh
 +
</pre>
 +
 
 +
Because the reconciler is all-or-nothing we try to run it only once per transaction. So in the post and postun sections we create a the file <code>/var/run/eclipse/run-reconciler</code> which will indicate that the reconciler needs to be run. In the posttrans section the eclipse-reconciler script checks for the presence of the file runs the reconciler once and remove the file. The reconciler will then install all new features and plugins and uninstall all missing features and plugins.
  
 
== Things to avoid ==
 
== Things to avoid ==
Line 135: Line 167:
 
== Specfile Template ==
 
== Specfile Template ==
 
<pre>
 
<pre>
%global eclipse_base        %{_libdir}/eclipse
 
  
 
Name:          eclipse-plugin
 
Name:          eclipse-plugin
Line 146: Line 177:
 
URL:            http://www.eclipse.org/plugin
 
URL:            http://www.eclipse.org/plugin
 
Source0:        org.eclipse.plugin-TAG-fetched-src.tar.bz2
 
Source0:        org.eclipse.plugin-TAG-fetched-src.tar.bz2
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 
Arch:          noarch
 
Arch:          noarch
  
Line 152: Line 182:
 
BuildRequires:  eclipse-pde
 
BuildRequires:  eclipse-pde
 
Requires:      eclipse-platform
 
Requires:      eclipse-platform
 +
BuildRequires:  eclipse-platform
 +
 +
Requires(post): eclipse-platform >= 1:3.7.1-15
 +
Requires(postun): eclipse-platform >= 1:3.7.1-15
  
 
%description
 
%description
Line 161: Line 195:
 
Requires: %{name} = %{version}-%{release}
 
Requires: %{name} = %{version}-%{release}
 
Group: Development/Tools
 
Group: Development/Tools
 +
Requires(post): eclipse-platform >= 1:3.7.1-15
 +
Requires(postun): eclipse-platform >= 1:3.7.1-15
  
 
%description b
 
%description b
 
%{name}-b enhances plugin with b-specific functionality.
 
%{name}-b enhances plugin with b-specific functionality.
 +
 +
%post b
 +
%_eclipse_pkg_post
 +
 +
%postun b
 +
%_eclipse_pkg_postun
 +
 +
%posttrans b
 +
%_eclipse_pkg_posttrans
  
 
%prep
 
%prep
Line 169: Line 214:
  
 
%build
 
%build
%{eclipse_base}/buildscripts/pdebuild -f org.eclipse.plugin_feature
+
%{_eclipse_base}/buildscripts/pdebuild -f org.eclipse.plugin_feature
  
%{eclipse_base}/buildscripts/pdebuild -f org.eclipse.plugin.b_feature
+
%{_eclipse_base}/buildscripts/pdebuild -f org.eclipse.plugin.b_feature
  
 
%install
 
%install
rm -rf $RPM_BUILD_ROOT
 
 
install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a
 
install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a
 
unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a \
 
unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a \
Line 181: Line 225:
 
build/rpmBuild/org.eclipse.plugin.b_feature.zip
 
build/rpmBuild/org.eclipse.plugin.b_feature.zip
  
%clean
+
%post
rm -rf $RPM_BUILD_ROOT
+
%_eclipse_pkg_post
 +
 
 +
%postun
 +
%eclipse_pkg_postun
 +
 
 +
%posttrans
 +
%eclipse_pkg_posttrans
  
 
%files
 
%files
Line 201: Line 251:
  
 
=== Common Defines ===
 
=== Common Defines ===
<code>%global eclipse_base %{_libdir}/eclipse</code>.
 
  
 
=== Requires ===
 
=== Requires ===
Line 239: Line 288:
  
 
However, we end up with the plugin classes themselves being expanded in the <code>org</code> directory.  [https://bugzilla.redhat.com/273881 Bug #273881]  causes build failures when building debuginfo packages in this case.  The acceptable workaround is to modify the build.properties file in the plugin to JAR the plugin code separately (ex. <code>mylyn-webcore.jar</code>) and include it within this expanded plugin directory.  An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewcvs/devel/eclipse-mylyn/ eclipse-mylyn]  (specifically the patches related to <code>org.eclipse.mylyn.webcore</code>).
 
However, we end up with the plugin classes themselves being expanded in the <code>org</code> directory.  [https://bugzilla.redhat.com/273881 Bug #273881]  causes build failures when building debuginfo packages in this case.  The acceptable workaround is to modify the build.properties file in the plugin to JAR the plugin code separately (ex. <code>mylyn-webcore.jar</code>) and include it within this expanded plugin directory.  An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewcvs/devel/eclipse-mylyn/ eclipse-mylyn]  (specifically the patches related to <code>org.eclipse.mylyn.webcore</code>).
 
=== OSGi ===
 
OSGi bundles contain metadata just like RPMs do.  This metadata can be used to automatically generate <code>Provides</code> and <code>Requires</code> similar to how it is done for mono packages.  This functionality exists in Fedora's current <code>rpm</code> package but requires some investigation as at the time of this writing it does not appear to be functioning properly.
 
  
 
=== rpmstubby ===
 
=== rpmstubby ===
<code>rpmstubby</code> is a small project that is part of the [http://eclipse.org/linuxtools linuxdistros project]  at eclipse.org.  Its aim is to make packaging Eclipse plugins as RPMs extremely simple.  It is still in its infancy, but specfiles for packages like <code>eclipse-mylyn</code> were originally stubbed out using it.  It is hoped that it can soon be provided as a tool to Fedora packagers.  Help is always welcome on the project and it can be checked out of svn here:  <code>svn://anonymous@dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/rpmstubby/trunk</code>.
+
<code>rpmstubby</code> is a small project that is part of the [http://eclipse.org/linuxtools linuxdistros project]  at eclipse.org.  Its aim is to make packaging Eclipse plugins as RPMs extremely simple.  Specfiles for packages like <code>eclipse-mylyn</code> were originally stubbed out using it.  Available as eclipse-rpmstubby package.
  
 
[[Category:Packaging guidelines]]
 
[[Category:Packaging guidelines]]

Revision as of 12:55, 6 February 2012

Contents

Packaging Eclipse Plugins

Glossary

  • Bundle: An "OSGi bundle".
  • Plugin: A functional unit of Eclipse functionality. Post-Eclipse 3.0, the term "plugin" can almost always be interchanged with the term "bundle". Colloquially, among non-Eclipse developers, the term is used to refer to a set of functional Eclipse plugins ex. "CDT".
  • Feature: A collection of plugins.
  • Fragment: A bundle with native elements ex. org.eclipse.core.filesystem.linux.${arch}

Introduction

Eclipse is a modular platform that can be used for building everything from server-side applications to full-blown graphical applications like the Eclipse IDE and Lotus Notes. Each of the modular blobs is referred to as a plugin or a bundle. In a nutshell, the system itself is a small runtime (Equinox) based on the OSGi specifications [see http://www.eclipse.org/equinox/ for more information] which loads and runs a given list of bundles. Most people think of Eclipse as a programming integrated development environment (IDE). This document details best practices for packaging Eclipse IDE plugins. Examples include adding Subversion functionality (eclipse-subclipse) and tools for tracking your tasks (eclipse-mylyn).

Naming

Eclipse plugin packages MUST be named eclipse-<projectname>. For example, a package of the anyedit plugin for Eclipse would by named eclipse-anyedit.

Binary RPM naming

If a project provides multiple features, package each of the features as a separate binary plugin, matching the naming and grouping of plugins directly.

Group Tag

There is no single Group tag for Eclipse plugins. Choose a Group that best fits the plugin and satisfies rpmlint. Some of the existing Groups include:

Development/Tools
Development/Languages
System Environment/Libraries

Source

Obtaining source for Eclipse plugins is sometimes difficult. Most projects do not release source tarballs so it is often necessary to create an archive from a source revision control system. Ensure that instructions for reproducing the source archive are included in comments in the specfile. These instructions can take the form of either explicit instructions as in eclipse-cdt or be put into a separate shell script as in eclipse-rpm-editor .

Remember that Eclipse plugin packages, like all Fedora software packages, must be built from source, and cannot contain any "pre-built" binary components.

Building

Eclipse plugins SHOULD be built with the Eclipse Plugin Development Environment (PDE; PDE Build specifically) because these builds are generally easier to maintain. ant builds are acceptable, but are generally more difficult to maintain. Following what upstream does is the best practice.

pdebuild

There is a script that makes invoking PDE Build easy: /usr/lib{,64}/eclipse/buildscripts/pdebuild:

usage: /usr/lib{,64}/eclipse/buildscripts/pdebuild [<options>] 

Use PDE Build to build Eclipse features

Optional arguments:
-h      Show this help message
-f      Feature ID to build
-d      Plugin dependencies in addition to Eclipse SDK
(space-separated, names on which to glob features and plugins)
-a      Additional build arguments (ex. -DjavacSource=1.5)
-j      VM arguments (ex. -DJ2SE-1.5=%{_jvmdir}/java/jre/lib/rt.jar)
-v      Be verbose
-D      Debug platform itself (passes -consolelog -debug to Eclipse)
-o      Orbit dependencies

File Locations

All platform-independent plugins/features should go into %{_datadir}/eclipse/dropins/<one word name of this feature or plugin>. JARs should therefore go into %{_datadir}/eclipse/dropins/<name>/plugins and features should go into %{_datadir}/eclipse/dropins/<name>/features. Architecture-specific plugins/features should go into %{_libdir}/eclipse/dropins/<one word name of this feature or plugin>. JARs should therefore go into %{_libdir}/eclipse/dropins/<name>/plugins and features should go into %{_datadir}/eclipse/dropins/<name>/features. Example:

%install
installDir=%{buildroot}%{_datadir}/eclipse/dropins/quickrex
install -d -m 755 $installDir
unzip -q -d $installDir \
 build/rpmBuild/de.babe.eclipse.plugins.QuickREx.zip

Arch vs. noarch

While many Eclipse plugins will be architecture-independent, there will be some that contain native parts. Plugins without native fragments should be noarch and go into %{_datadir}/eclipse/dropins and plugins with native fragments should be arch-dependent and go into %{_libdir}/eclipse/dropins.

Running the Reconciler

Starting with Fedora 17 all Eclipse plugin and feature RPMS must run the reconciler after installation.

To add support for this in your packages you have to create %post, %postun and %posttrans sections. and add the eclipse macros as follows:

BuildRequires:    eclipse-platform

%package [subpackage name]
...
Requires(post): eclipse-platform >= 1:3.7.1-15 
Requires(postun): eclipse-platform >= 1:3.7.1-15

%post [subpackage name]
%_eclipse_pkg_post

%postun [subpackage name]
%_eclipse_pkg_postun

%posttrans [subpackage name]
%_eclipse_pkg_posttrans

As you will have noticed in the example above you also need to add post and postun requirements on eclipse-platform to your packages' package section in the specfile. In addition you must make sure that you have a direct or indirect build requirement on eclipse-platform >= 1:3.7.1-15.

At this point you will be done, but if you want the details please keep reading. RPM places all the plugin artifacts in the proper directories. However that does not update the eclipse metadata. This means that until the next time eclipse starts it is unaware of the newly installed plugins. Because the user would normally run eclipse not as root Eclipse does not have permission to write to the meta data files located in the installation directory. It therefore creates a parallel version in the user's home directory ~/.eclipse. This creates a fragile installation and leads to a whole host of problems. To avoid this we run the Eclipse reconciler during rpm installation. The eclipse reconciler is an Eclipse application which goes through checks the installation directories and updates the eclipse metadata with any newly installed plugins.

Here is an example from the eclipse-emf spec file for the eclipse-rse-sdk rpm:

BuildRequires:    eclipse-platform >= 1:3.7.1-15

%package sdk
[...]
Requires(post): eclipse-platform >= 1:3.7.1-15 
Requires(postun): eclipse-platform >= 1:3.7.1-15

%post sdk
%_eclipse_pkg_post

%postun sdk
%_eclipse_pkg_postun

%posttrans sdk
%_eclipse_pkg_posttrans

The above macros expand to the following:

%package sdk
[...]

Requires(post): eclipse-platform >= 1:3.7.1-15 
Requires(postun): eclipse-platform >= 1:3.7.1-15

%post sdk 
touch /var/run/eclipse/run-reconciler 

%postun sdk
touch /var/run/eclipse/run-reconciler 

if [ $1 == 0 ]; then 
  eclipse-reconciler.sh 
fi 

%posttrans sdk 
eclipse-reconciler.sh

Because the reconciler is all-or-nothing we try to run it only once per transaction. So in the post and postun sections we create a the file /var/run/eclipse/run-reconciler which will indicate that the reconciler needs to be run. In the posttrans section the eclipse-reconciler script checks for the presence of the file runs the reconciler once and remove the file. The reconciler will then install all new features and plugins and uninstall all missing features and plugins.

Things to avoid

Pre-built binaries

If Eclipse plugins depend upon third party libraries (and licensing permits it), developers often include these libraries directly in their source control system. In this case, the libraries must exist as other packages in Fedora and their contents (such as their JARs) be symlinked from within the source and build trees of the Eclipse plugin being packaged. While it may make source archives smaller in size if they are cleansed of these pre-built files, it is not necessary to do so unless the libraries themselves are not redistributable. Binary RPMs MUST NOT include pre-built files.

Note.png A simple check which may be run at the end of %prep (courtesy David Walluck (I think that's who gave it to Ben Konrath)):

JARS=""
for j in $(find -name \*.jar); do
if [ ! -L $j ] ; then
JARS="$JARS $j"
fi
done
if [ ! -z "$JARS" ] ; then
echo "These JARs should be deleted and symlinked to system JARs: $JARS"
exit 1
fi

Differing from upstream

Plugins that are jarred should remain jarred and those that are expanded should be expanded in their RPM. There are two cases (that we can think of as of this writing) that warrant diverging from upstream:

  1. Symlinking to a binary JAR from another package
  2. Expanding a JAR to allow for symlinking to a binary JAR from another package

See below for a tip on how to deal with the expanded JAR case.

Specfile Template


Name:           eclipse-plugin
Version:        1.0
Release:        1%{?dist}
Summary:        Plugin provides such and such functionality for the Eclipse IDE.

Group:          Development/Tools
License:        EPL
URL:            http://www.eclipse.org/plugin
Source0:        org.eclipse.plugin-TAG-fetched-src.tar.bz2
Arch:           noarch

BuildRequires:  java-devel >= 1.5.0
BuildRequires:  eclipse-pde
Requires:       eclipse-platform
BuildRequires:  eclipse-platform

Requires(post): eclipse-platform >= 1:3.7.1-15 
Requires(postun): eclipse-platform >= 1:3.7.1-15

%description
Plugin provides such and such functionality for the Eclipse IDE.
Specific functionality b is provided in %{name}-b.

%package b
Summary: b functionality for plugin
Requires: %{name} = %{version}-%{release}
Group: Development/Tools
Requires(post): eclipse-platform >= 1:3.7.1-15 
Requires(postun): eclipse-platform >= 1:3.7.1-15

%description b
%{name}-b enhances plugin with b-specific functionality.

%post b
%_eclipse_pkg_post

%postun b
%_eclipse_pkg_postun

%posttrans b
%_eclipse_pkg_posttrans

%prep
%setup -q org.eclipse.plugin

%build
%{_eclipse_base}/buildscripts/pdebuild -f org.eclipse.plugin_feature

%{_eclipse_base}/buildscripts/pdebuild -f org.eclipse.plugin.b_feature

%install
install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a
unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a \
build/rpmBuild/org.eclipse.plugin_feature.zip
unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-b \
build/rpmBuild/org.eclipse.plugin.b_feature.zip

%post
%_eclipse_pkg_post

%postun
%eclipse_pkg_postun

%posttrans
%eclipse_pkg_posttrans

%files
%{_datadir}/eclipse/dropins/plugin-a

%files b
%{_datadir}/eclipse/dropins/plugin-b

%changelog
* Fri Oct 17 2008 Andrew Overholt <overholt redhat com> 1.0-2
- Update for Eclipse 3.4.x

* Fri Feb 29 2008 Andrew Overholt <overholt@redhat.com> 1.0-1
- Initial Fedora package

Tips and Notes

Common Defines

Requires

Until rpmstubby (see below) is released and/or more widespread, Requires on bits provided by the Eclipse SDK (RCP, SWT, Platform, JDT, PDE, CVS, etc.) should only be on the binary package providing the required functionality (ex. eclipse-cvs-client or eclipse-rcp). For IDE features, the most common requirement will be eclipse-platform.

Features vs. Plugins

Eclipse features are groups of plugins. They are preferred, but not required since they provide nice demarcation lines for binary RPMs. We generally try to make binary RPMs mirror upstream features. Eclipse features also work nicely with rpmstubby (see below), but not all plugins have features.

JAR Expansion

In rare cases it may be necessary to symlink to something inside a JAR. This situation is often referred to as "nested JARs". If the plugin code itself is not enclosed in a nested JAR, expansion will result in a directory structure containing class files. This is best illustrated with an example:

$ unzip -l org.eclipse.mylyn.web.core_2.2.0.I20071220-1700.jar | grep jar$
46725  12-20-07 20:08   lib-httpclient/commons-codec-1.3.jar
279781  12-20-07 20:08   lib-httpclient/commons-httpclient-3.0.1.jar
38015  12-20-07 20:08   lib-httpclient/commons-logging-1.0.4.jar
26202  12-20-07 20:08   lib-httpclient/commons-logging-api-1.0.4.jar
153253  12-20-07 20:08   lib-rome/jdom-1.0.jar
197290  12-20-07 20:08   lib-rome/rome-0.8.jar
26624  12-20-07 20:08   lib-xmlrpc/ws-commons-util-1.0.1-sources.jar
34840  12-20-07 20:08   lib-xmlrpc/ws-commons-util-1.0.1.jar
35142  12-20-07 20:08   lib-xmlrpc/xmlrpc-client-3.0-sources.jar
43312  12-20-07 20:08   lib-xmlrpc/xmlrpc-client-3.0.jar
91225  12-20-07 20:08   lib-xmlrpc/xmlrpc-common-3.0-sources.jar
98051  12-20-07 20:08   lib-xmlrpc/xmlrpc-common-3.0.jar

Note that we have embedded JARs which we would like to turn into symlinks to existing JARs (from other packages). If we simply unzip the plugin JAR and symlink, one would think we would be okay:

$ unzip -qq org.eclipse.mylyn.web.core_2.2.0.I20071220-1700.jar
$ rm !$
$ ls
about.html  lib-httpclient  lib-rome  lib-xmlrpc  META-INF  org
$ <do symlinking here>

However, we end up with the plugin classes themselves being expanded in the org directory. Bug #273881 causes build failures when building debuginfo packages in this case. The acceptable workaround is to modify the build.properties file in the plugin to JAR the plugin code separately (ex. mylyn-webcore.jar) and include it within this expanded plugin directory. An example of this work-around can be seen in eclipse-mylyn (specifically the patches related to org.eclipse.mylyn.webcore).

rpmstubby

rpmstubby is a small project that is part of the linuxdistros project at eclipse.org. Its aim is to make packaging Eclipse plugins as RPMs extremely simple. Specfiles for packages like eclipse-mylyn were originally stubbed out using it. Available as eclipse-rpmstubby package.