[fedora-java] Re: Eclipse 3.4

Robert Marcano robert at marcanoonline.com
Thu Jul 31 19:32:19 UTC 2008


On Thu, 2008-07-31 at 15:07 -0400, Andrew Overholt wrote:
> Hi,
> 
> I've finally got version 3.4 of the Eclipse SDK ready to go, targetting
> Fedora 10:
> 

Good news, looks like the Subversive plugin still is not part of the
base platform like CVS, I am maintaining the subclipse package but it
had not much activity recently. ummmm maybe I should try it.

is someone working on packaging another Ganymede subprojects? just
yesterday I had to install as a requirement for m2eclipse (Maven
integration plugins needed to work with JBoss EJB3 sources from
eclipse), and I do not like any non OS updater :-). I remember that EMF
was previously packaged


> 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.




More information about the fedora-devel-java-list mailing list