java-devel November 2011

java-devel@lists.fedoraproject.org

9 participants
7 discussions

Improvements Eclipse Installation
by sami wagiaalla 15 Feb '12

15 Feb '12

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

2 6

Shared library paths for native linker
by Petr Pisar 23 Jan '12

23 Jan '12

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

6 9

Re: [fedora-java] [Pki-devel] CMake 'JNI' macro question . . .
by Adam Young 05 Dec '11

05 Dec '11

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

3 3

Re: [fedora-java] [Pki-devel] CMake 'JNI' macro question . . .
by Adam Young 30 Nov '11

30 Nov '11

Cross posting to Java devel as there might be a an answer from the Java/Fedora side of the house 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

1 0

Re: [fedora-java] Improvements Eclipse Installation
by sami wagiaalla 29 Nov '11

29 Nov '11

> [...] One note, I don't like macros that span multiple scriptlets. > Having a macro for each scriptlet (or forgoing a macro if the resulting code > is simple enough) seems to be about the right level of indirection. > It does not look pretty I agree, but my motivation is to make things simple for plugin packagers. Also, it makes it simple to update the macro when bugs show up without having to update the packages with additional macros. They just get the update when they are rebuilt. Sami

1 1

Java 7 can't understand some chars
by Ismael Olea 21 Nov '11

21 Nov '11

Hi: I've updated OmegaT for F15 and F16[1] without novelty. But compiling in rawhide showed a strange to me error: «error: unmappable character for encoding ASCII»[2]. In a first approach the suspects were some strange coded chars (which 1.6 can eat, btw) but after patching them I found in local tests the same error with the 'ß' letter [3]. The file codification seems to be common UTF-8. I'm not a programmer at all but this sounds _very_ weird to me. Is anybody aware if openjdk 1.7 has some bug related with UNICODE or similar? I didn't find anything like this in BZ. Any other idea? [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=275068 [2] http://koji.fedoraproject.org/koji/getfile?taskID=3529868&name=build.log [3] see line 232 at http://omegat.svn.sourceforge.net/viewvc/omegat/branches/release-2-3/src/or… -- Ismael Olea http://olea.org/diario/

3 5

Automatic javadoc subpackage genration
by Stanislav Ochotnicky 07 Nov '11

07 Nov '11

Hi list, We have already discussed automatic javadoc subpackage generation during our SIG meeting few months back [1]. At the time we had two issues with it: * it didn't handle licensing (javadoc has to have license of its own if upstream provides it or require main package) * we'd still have to copy javadocs into %_javadocdir Yesterday I decided to look into this and created a bit more convoluted macro with more options. See [2] or [3] for details. Basically we try to do everything automatically but allow packagers to modify behaviour of the macro: * Specify non-standard location where we can find license (until we add it to standard paths macro looks into) * Specify directory where apidocs are generated (we default to maven-generated target/site/apidocs) * Allow packager to override adding of "Requires: %{name}.." into javadoc (we do this if we don't find license file). This is useful when upstream has no separate license file Also, I hooked into RPM so the javadocs are copied to %{_javadocdir} automatically without any intervention needed from packager. As far as I know this should cover most use-cases, but I am looking for feedback before proposing changes to the guidelines. [1] http://meetbot.fedoraproject.org/fedora-meeting/2011-06-01/java-sig.2011-06… [2] http://inputvalidation.blogspot.com/2011/11/automatic-javadoc-subpackage-ge… [3] http://git.fedorahosted.org/git?p=javapackages.git;a=summary (generate_javadoc branch) -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel November 2011