The way we currently install Eclipse plugins in Fedora is incorrect and
RPM places all the plugin artifacts in the proper directories. However
that does not update the eclipse metadata. This means that until the
next time eclipse starts it is unaware of the newly installed plugins.
Because the user would normally run Eclipse not as root Eclipse does not
have permission to write to the meta data files located in the
installation directory. It therefore creates a parallel version in the
user's home directory ~/.eclipse. This creates a fragile installation
and leads to a whole host of problems.
To improve this I have written apatch which runs the Eclipse reconciler
during rpm installation. The Eclipse reconciler is an Eclipse
application which goes through and checks the installation directories
and updates the eclipse metadata with any newly installed plugins.
To add support for this in your eclipse package you have to add the
following line to your rpm spec file:
%_eclipse_pkg [package name]
Here is an example from the eclipse-rse spec file for the
The above macro expands to the following:
if [ $1 == 0 ]; then
I apologize if you have experienced instability in Eclipse installations
on rawhide, it is probably due to these changes. Please let me know if
you have any comments questions or suggestions.
I will be filing a request to update the Eclipse packaging guidelines.
If you are interested in the details of the work, here is a summary in
the form of a patch: http://fpaste.org/pPEC/
I've just committed and built new maven2 rpms. It means there is no
longer any mvn2 or mvn-jpp script in rawhide. Also about 1/2 of the
artifacts are not even being built since we wanted to strip down BR/R
to bare minimum.
Maven2 still contains subpackages with jars being used by some other
projects that do not have replacements in maven 3.x land and we'll
keep it going as long as possible.
I would be strongly against resurrection of m2, but if someone can
show he'll take care of it...he/she can revert my commits and become new
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Red Hat Inc. http://cz.redhat.com
I have a non-java package (pl) which links to jvm. Build scripts of pl
needs to locate directories with libjava.so, libjvm.so etc. and instruct
native linker (ld) where to find them (-L option).
Current implementation in the pl.spec is uggly (a lot of ad-hoc hacks for
each platform which requires tuning time to time
So I decided to find ultimate way how to obtain path for linker and Java
home directory. Unfortunatelly, I did not find any. So I've written
one. You can find it as attachment at the afore-mentioned bug report.
Usage is inspired by pkg-config:
$ javac JavaConfig.java
$ java JavaConfig --home
$ java JavaConfig --libs-only-L
-L/usr/java/packages/lib/amd64 -L/usr/lib64 -L/lib64 -L/lib -L/usr/lib
I can bundle the tool to my `pl' package, but I think it could be
helpful for others too. So I'd like to ask Java SIG whether it wants to
adopt it (e.g. as a part of JDK).
I have spent the last few days (on and off) trying to gather a list of
packages that need to be updated for Java 7 in rawhide. I have
identified 31 packages that fail to build (almost all trivial/easy to
fix), and some more that hard code a Java 6 requirement.
I have created a wiki page listing all the packages, the issues, and
how to fix them:
It'd be great if everyone could please volunteer to fix some of them. If
you have ProvenPackager status and have time, please add your name to
the list of ProvenPackagers on that page so that those without access
can send you their fixes.
I will be applying for ProvenPackager status myself and will add my name
to that list if/when I get it.