(%define => %global) |
(Add categories) |
||
Line 247: | Line 247: | ||
=== 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. 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>. | ||
[[Category:Packaging guidelines]] |
Revision as of 17:42, 17 February 2010
Packaging Eclipse Plugins
Glossary
- Plugin1: 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".
- Plugin2: The colloquial name given to a set of functional Eclipse plugins ex. "CDT". More common usage among non-Eclipse developers than the above definition.
- Feature: A collection of plugin1s.
- 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
As of Fedora 9, there is a script that makes invoking PDE Build easy: /usr/lib{,64}/eclipse/buildscripts/pdebuild
(in Fedora 9 the script is located at /usr/share/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
Note: PDE Build must be called explicitly in Fedora 8 and earlier (including EPEL 5). The following snippet may be used to replace the
pdebuild
call in the template:
/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} <other dependencies ex. cdt> mkdir home SDK=$(cd SDK > /dev/null && pwd) homedir=$(cd home > /dev/null && pwd) java -cp $SDK/startup.jar \ -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ 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>
EPEL 5
The copy-platform
script is in a different location on RHEL 5 than it is in Fedora. If calling copy-platform
explicitly, the following snippet may be useful to facilitate building Eclipse plugins for EPEL 5:
%if 0%{?rhel} == 5 /bin/sh -x %{_libdir}/eclipse/buildscripts/copy-platform SDK %{eclipse_base} %else /bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} %endif
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 rm -rf %{buildroot} installDir=%{buildroot}%{_datadir}/eclipse/dropins/quickrex install -d -m 755 $installDir unzip -q -d $installDir \ build/rpmBuild/de.babe.eclipse.plugins.QuickREx.zip
For Fedora 9, all plugin jars should go into %{_datadir}/eclipse/plugins
and features should go into %{_datadir}/eclipse/features
. The only exception is for fragments which should go into %{_libdir}/eclipse/plugins
(and features
if applicable). Note that this is not reflected in the template below.
Arch vs. noarch
While many Eclipse plugins will be architecture-independent, please follow the ["Packaging/GCJGuidelines"] with regards to gcj
ahead-of-time compilation. As those guidelines specify, gcj
-compiled packages are arch-dependent and are thus not noarch
.
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.
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:
- Symlinking to a binary JAR from another package
- 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
%global eclipse_base %{_libdir}/eclipse 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 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Arch: noarch BuildRequires: java-devel >= 1.5.0 BuildRequires: eclipse-pde Requires: eclipse-platform %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 %description b %{name}-b enhances plugin with b-specific functionality. %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 rm -rf $RPM_BUILD_ROOT 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 %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %{_datadir}/eclipse/dropins/plugin-a %files b %defattr(-,root,root,-) %{_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
%global eclipse_base %{_libdir}/eclipse
.
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
).
OSGi
OSGi bundles contain metadata just like RPMs do. This metadata can be used to automatically generate Provides
and Requires
similar to how it is done for mono packages. This functionality exists in Fedora's current rpm
package but requires some investigation as at the time of this writing it does not appear to be functioning properly.
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. It is still in its infancy, but specfiles for packages like eclipse-mylyn
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: svn://anonymous@dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/rpmstubby/trunk
.