[fedora-java] Separate ecj SRPM
Hi,
We'd like to enable an RPM script that mirrors OSGi Require-Bundle,
Import-Package, and Export-Package statements into RPM virtual Requires
and Provides [0]. While testing this, Alphonse van Assche discovered
that our eclipse-ecj package should actually Require eclipse-rcp [1].
eclipse-rcp also includes SWT which itself needs a bunch of GNOME
libraries and XULRunner. I don't think we want java-gcj-compat dragging
in XULRunner and a bunch of GNOME libraries.
Therefore, I think we need to have a separate ecj SRPM/RPM [2]. I have
whipped up a simple one for use by java-gcj-compat and put it here:
http://overholt.fedorapeople.org/ecj-3.4.2-1.fc10.src.rpm
The java-gcj-compat maintainers will have to own it and therefore test
it out. I don't anticipate any issues, but please test it ASAP so we
can deal with any fallout. Once it's been deemed acceptable, it will
have to go through a review which I probably shouldn't do :) Then, the
eclipse package will need to:
- remove all references to ecj
- keep jdtcore symlinks but not ecj symlinks
- move jdtcore symlinks to -jdt package and remove -ecj package
This is all pretty minor and can be done very quickly. Ideally we'd get
it done before the beta freeze on Tuesday. If we can't get it done by
then, we could perhaps justify the minor changes for after the freeze or
wait until F-12.
Thanks,
Andrew
[0]
Having automatic and correct OSGi bundle-level requirements matched in
our RPMs will be very nice. We will obviously still need BuildRequires
but we'll know at install time if there will be an error with OSGi
dependency resolution at runtime.
[1]
This is because our eclipse-ecj package contains the
org.eclipse.jdt.core plugin which needs org.eclipse.core.runtime among
other stuff and core.runtime is in the RCP feature. Note that the new
ecj package will contain just the batch compiler part of jdt.core -- as
opposed to the entire thing like we do now -- so it won't have the
dependency on any RCP bundles at the OSGi level (in fact, it won't even
be an OSGi bundle).
[2]
There are other benefits to a standalone ecj SRPM, of course:
- we don't need to patch org.eclipse.jdt.core and diverge from upstream
- GCCMain -- the gcj driver for ecj -- can go into the ecj JAR and not
jdt.core itself
- bootstrapping a full gcc SRPM no longer requires the output of
building an eclipse SRPM
One concern is that RHEL-5 has an unversioned Obsoletes/Provides on
"ecj" which should probably get fixed.