Hi,
I have a few updates to the Eclipse Plugin packaging guidelines. They
include some clarifications, typos, and updates for Eclipse 3.4.x. The
only bit of real substance is modifying the template to note how we're
using the dropins mechanism for plugin installation in 3.4.x and above.
I've attached a diff 'cause I don't think I can commit it. Can someone
else?
Thanks,
Andrew
--- EclipsePlugins.orig.txt 2008-10-17 10:17:07.000000000 -0400
+++ EclipsePlugins.txt 2008-10-17 10:37:25.000000000 -0400
@@ -36,10 +36,10 @@
Eclipse plugins 'SHOULD' be built with the Eclipse Plugin Development Environment (PDE; PDE Build specifically) because these builds are generally easier to maintain. <code>ant</code> 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: <code>/usr/share/eclipse/buildscripts/pdebuild</code>:
+As of Fedora 9, there is a script that makes invoking PDE Build easy: <code>/usr/lib{,64}/eclipse/buildscripts/pdebuild</code>:
<pre>
-usage: /usr/share/eclipse/buildscripts/pdebuild [<options>]
+usage: /usr/lib{,64}/eclipse/buildscripts/pdebuild [<options>]
Use PDE Build to build Eclipse features
@@ -52,6 +52,7 @@
-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
</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:
@@ -80,7 +81,7 @@
</pre>
==== EPEL 5 ====
-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 Eclipse plugins for EPEL 5:
+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:
<pre>
%if 0%{?rhel} == 5
/bin/sh -x %{_libdir}/eclipse/buildscripts/copy-platform SDK %{eclipse_base}
@@ -90,14 +91,23 @@
</pre>
== File Locations ==
-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).
+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>
+%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
+</pre>
== Arch vs. noarch ==
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>.
== 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.
+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.
{{Template:Note}} A simple check which may be run at the end of <code>%prep</code> (courtesy David Walluck (I think that's who gave it to Ben Konrath)):
<pre>
@@ -108,21 +118,21 @@
fi
done
if [ ! -z "$JARS" ] ; then
-echo "These jars should be deleted and symlinked to system jars: $JARS"
+echo "These JARs should be deleted and symlinked to system JARs: $JARS"
exit 1
fi
</pre>
=== 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
-1. Expanding a jar to allow for symlinking to a binary jar from another package
+# 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.
+See below for a tip on how to deal with the expanded JAR case.
== Specfile Template ==
<pre>
-%define eclipse_base %{_datadir}/eclipse
+%define eclipse_base %{_libdir}/eclipse
Name: eclipse-plugin
Version: 1.0
@@ -162,10 +172,10 @@
%install
rm -rf $RPM_BUILD_ROOT
-install -d -m 755 $RPM_BUILD_ROOT%{eclipse_base}
-unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/..
+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%{eclipse_base}/..
+unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-b
build/rpmBuild/org.eclipse.plugin.b_feature.zip
%clean
@@ -173,23 +183,16 @@
%files
%defattr(-,root,root,-)
-%{eclipse_base}/plugins/org.eclipse.plugin.a_*.jar
-%{eclipse_base}/plugins/org.eclipse.plugin.c_*.jar
-%dir %{eclipse_base}/features/org.eclipse.plugin_feature_*
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/license.html
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/about.html
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/epl-v10.html
-%{eclipse_base}/features/org.eclipse.plugin_feature_*/feature.xml
+%{_datadir}/eclipse/dropins/plugin-a
%files b
%defattr(-,root,root,-)
-%{eclipse_base}/plugins/org.eclipse.plugin.b_*.jar
-%dir %{eclipse_base}/features/org.eclipse.plugin.b_feature_*
-%doc %{eclipse_base}/features/org.eclipse.plugin.b_feature_*/license.html
-%doc %{eclipse_base}/features/org.eclipse.plugin.b_feature_*/epl-v10.html
-%{eclipse_base}/features/org.eclipse.plugin.b_feature_*/feature.xml
+%{_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
</pre>
@@ -197,7 +200,7 @@
== Tips and Notes ==
=== Common Defines ===
-<code>%define eclipse_base %{_datadir}/eclipse</code> and, if necessary <code>%define eclipse_lib_base %{_libdir}/eclipse</code>.
+<code>%define eclipse_base %{_libdir}/eclipse</code>.
=== Requires ===
Until <code>rpmstubby</code> (see below) is released and/or more widespread, <code>Requires</code> 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. <code>eclipse-cvs-client</code> or <code>eclipse-rcp</code>). For IDE features, the most common requirement will be <code>eclipse-platform</code>.
@@ -224,7 +227,7 @@
98051 12-20-07 20:08 lib-xmlrpc/xmlrpc-common-3.0.jar
</pre>
-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:
+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:
<pre>
$ unzip -qq org.eclipse.mylyn.web.core_2.2.0.I20071220-1700.jar
@@ -234,7 +237,7 @@
$ <do symlinking here>
</pre>
-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.
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
Updates to Eclipse Plugin packaging guidelines
