Improvements Eclipse Installation
by sami wagiaalla
Hi,
The way we currently install Eclipse plugins in Fedora is incorrect and
somewhat fragile.
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
eclipse-rse-sdk rpm:
%package sdk
[...]
%_eclipse_pkg sdk
The above macro expands to the following:
%post sdk
touch /var/run/eclipse/run-reconciler
%postun sdk
touch /var/run/eclipse/run-reconciler
if [ $1 == 0 ]; then
eclipse-reconciler.sh
fi
%posttrans sdk
eclipse-reconciler.sh
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/
Cheers,
Sami
11 years, 9 months
Shared library paths for native linker
by Petr Pisar
Hello,
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
<https://bugzilla.redhat.com/show_bug.cgi?id=740897>).
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
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
$ java JavaConfig --libs-only-L
-L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server
-L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64
-L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64
-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).
-- Petr
11 years, 10 months
orphaning of packages
by Permaine Cheung
Hi,
As I don't have time to maintain the following packages that I own, it
would be great if someone more active can take over the ownership, I
have orphaned them:
adaptx -- AdaptX XSLT processor and XPath engine
ant -- Ant build tool for java
asm2 -- A code manipulation tool to implement adaptable systems
avalon-framework -- Java components interfaces
avalon-logkit -- Java logging toolkit
axis -- A SOAP implementation in Java
bcel -- Byte Code Engineering Library
bsf -- Bean Scripting Framework
bsh -- Lightweight Scripting for Java
castor -- An open source data binding framework for Java
concurrent -- Utility classes for concurrent Java programming
jakarta-commons-httpclient -- Jakarta Commons HTTPClient implements the
client side of HTTP standards
objectweb-anttask -- ObjectWeb Ant task
plexus-archiver -- Plexus Archiver Component
plexus-i18n -- Plexus I18N Component
tagsoup -- A SAX-compliant HTML parser written in Java
xmlunit -- Provides classes to do asserts on xml
Thanks to akurtakov, sochotni and others who have been helping in
maintaining these packages.
Cheers,
Permaine
11 years, 12 months
Re: [fedora-java] [Pki-devel] CMake 'JNI' macro question . . .
by Adam Young
Cross posting to the Java Devel list
On 11/29/2011 09:53 PM, Matthew Harmsen wrote:
> Andreas,
>
> I would like to request your assistance on the following 'CMake' issue
> requested by Adam:
>
> * https://fedorahosted.org/pki/ticket/9
>
> Basically, on Fedora 16 and later, the default location of Java Native
> Interface (JNI) jar files was
> changed to reside under '/usr/lib/java' for 32-bit platforms, and
> '/usr/lib64/java' for 64-bit platforms.
>
> Per the TRAC ticket, I made a change in the spec files to handle this
> via the 'jpackage-utils' RPM.
> However, I do not know if 'CMake' can change the
> 'JAVA_LIB_INSTALL_DIR' macro located in
> the 'pki/cmake/Modules/DefineInstallationPaths.cmake' file to rely on
> the '%{_jnidir}' macro of
> 'jpackage-utils' stored in the '/etc/rpm/macros.jpackage', or if there
> is a different way of handling
> this where the following logic comes into play:
>
> * '/usr/lib/java' on RHEL 6 and earlier (32-bit AND 64-bit platforms)
> * '/usr/lib/java' on Fedora 15 and earlier (32-bit AND 64-bit platforms)
> * '/usr/lib/java' on Fedora 16 and later (32-bit platforms)
> * '/usr/lib/java' on Fedora 16 and later (using a 32-bit JVM on
> 64-bit platforms)
> o I am fairly confident that this case may actually REQUIRE a
> compiler override, as it does
> not look as if 'jpackage-utils' computes its '%{_jnidir}'
> macro based upon the 'JVM' architecture
> being utilized, but rather the '%{_libdir}' macro based upon
> the operating system architecture
> located in the appropriate
> '/usr/lib/rpm/platform/<platform>/macros' file
> * '/usr/lib64/java' on Fedora 16 and later (64-bit platforms)
>
> Your assistance on this matter is greatly appreciated.
>
> Eventually, do you think that we may want the appropriate logic added
> to the '/etc/rpm/macros.cmake' file?
>
> Thanks,
> -- Matt
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
12 years
