Hi,
I've finally got version 3.4 of the Eclipse SDK ready to go, targetting
Fedora 10:
http://koji.fedoraproject.org/koji/buildinfo?buildID=58121
(See [1] for an in-progress build with some minor fixes.)
Action item for plugin package maintainers:
-------------------------------------------
Please look at the relevant attached patches and apply them or something
like them in the devel directory of your plugin(s). Feel free to commit
and tag but note that you won't be able to build until I tag the build
for rawhide.
Email me personally if you have questions. Please also let me know when
you're finished and I can do koji builds of everything in the right
order (chain-build or otherwise). I'd like to do this very soon so
please take a few minutes to apply the changes.
Testing of the above build is greatly appreciated.
-------------------------------------------
There are a few minor changes for packagers of plugins/features:
- Bits are now installed to %{_libdir}/eclipse instead of
%{_datadir}/eclipse. This brings us in line with upstream's file layout
and avoids the crazy split-install osgi.sharedConfiguration.area hack.
It's also what Debian does, FWIW.
- p2 is the new provisioning platform in 3.4. Essentially it replaces the
old update manager but does other things as well. It requires
Eclipse-based apps to use profiles -- like Mozilla profiles -- and manage
them using its "director". In order to avoid fragile %post scriptlets,
we're going to use the "dropins mechanism" for plugin installation. This
means that all non-Eclipse platform plugins will be installed into their
own directory under %{_libdir}/eclipse/dropins. There are a variety of
layouts that are acceptable to p2, but we'll largely be going with
dropins/eclipse/<short name>/{plugins,features}. This has the nice side
benefit of simplifying %files sections :) . See [2] for more
information here.
- I added a flag to the pdebuild script to allow for Orbit-style
dependencies. If you don't know what this means, that's okay, but if
a plugin you want to package uses Orbit dependencies, you'll want to
use the -o flag to pdebuild. Plugins that use non-Eclipse JARs but
don't have a lib directory with JARs are probably using Orbit-style
dependencies. They'll have Require-Bundle or Import-Package entries
in their plugin MANIFEST.MFs. See eclipse-mylyn for an example of how
to use pdebuild in this case.
- I've renamed (and Obsoleted/Provided) libswt3-gtk2 to eclipse-swt. I
can't count the number of times people have been confused by this
naming and since we're not going to ship swt2 or swt.motif any time
soon, the naming is silly. I also folded pde-runtime into pde since
PHPEclipse no longer needs the separate pde-runtime package.
Outside of the CDT and the SELinux tools (both maintainers are working on
the necessary changes themselves), I've got patches for all of the plugins
we have as packages in Fedora. I've attached these patches and CC'd all of
the maintainers.
I will update the packaging guidelines very soon with the above
information.
Thanks,
Andrew
[1]
Build with branding fixed and removing some unnecessary Requires(post)
and the pde-runtime package which is now folded into pde:
http://koji.fedoraproject.org/koji/taskinfo?taskID=750696
[2]
There are some performance considerations here. Since it's generating
the associated metadata and "provisioning" the bits on the fly based on
files dropped into a directory, users may notice a slightly longer
startup the first time they start the Eclipse IDE after installing a new
plugin package. Subsequent startups won't be impacted. There is a lot
of performance improvement work going on upstream and much of it will
land in 3.4.1. If 3.4.1 is released early enough, we'll ship it in
Fedora 10. If not, we can ship it as an update. Should testing between
now and Fedora 10 show unacceptably poor performance (I haven't noticed
this in my own testing), we can look at back-porting some of the
performance work. The other main way of speeding up dropins-installed
plugins is by shipping pre-generated p2 metadata (like yum metadata).
I've experimented with this and think I can make it so that we
transparently generate it via pdebuild meaning it would only require a
rebuild of Fedora plugin packages. Things will work without these
generated content.xml files so in the interest of getting testing sooner
rather than later, I'm going to push ahead without the metadata for
dropins.