java-devel February 2012

java-devel@lists.fedoraproject.org

11 participants
9 discussions

Jetty 8.1.0 in a working state - test request
by Stanislav Ochotnicky 23 Feb '12

23 Feb '12

I have just pushed an updated jetty 8.1.x into rawhide and F17[1]. Most of the things should work and it would be nice if it got some wider testing since we updated from 6.x to 8.1.x between F16 and F17. If you have a web application or anything that you use with jetty, please try it out and report any bugs you encounter. The spec has been done from the group up more-less, so even trivial bugs can start appearing (i.e such as user creation that was broken in first releases). [1] https://admin.fedoraproject.org/updates/jetty-8.1.0-3.fc17 -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

1 0

Versioned java dep in packaging guidelines
by Garrett Holmstrom 22 Feb '12

22 Feb '12

Hi, The Java packaging guidelines [1] currently require a versioned dependency on java: At a minimum, Java packages MUST: BuildRequires: java-devel [>= specific_version] BuildRequires: jpackage-utils Requires: java >= specific_version Requires: jpackage-utils This does not seem to reflect reality, as many recently-approved packages do not require a minimum version. Can the mandatory java version be made optional like the java-devel one? [1] https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires

1 0

GlassFish JAXB and rebundling
by juan.hernandez＠redhat.com 20 Feb '12

20 Feb '12

Hello, I am currently trying to cleanup the GlassFish JAXB package and I found something that would like to discuss with you. The build process of this package ends by adding to the jaxb-xjc.jar file the contents of other jar files like codemodel.jar, istack-commons-tools.jar, etc. In Fedora those jars are in other packages. I think that this is not correct: whoever wants to use jaxb-xjc.jar should instead add to the classpath the other .jar files. What do you think? Regards, Juan Hernandez

3 2

Fedora vs JPackage naming
by Andy Grimm 17 Feb '12

17 Feb '12

After running into a few complicated naming situations, I decided it would be worthwhile to pose this question to the list. For context, the current Fedora package naming guidelines say this: "When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision." In the java world, a few issues come into play. 1) the history of jpackage naming, where a packages are often named according to the section of the apache project from which they came. 2) the upstream tarball naming and jar file names, which typically lack the "ws-commons" prefix. 3) the existing Fedora packages, where we have apache-commons-* , xml-commons-*, one ws-commons-* package, and one ws-* package. 4) apache's own naming in github is different from their svn naming (partly due to a lack of hierarchy): https://github.com/apache/webservices-axiom versus http://svn.apache.org/viewvc/webservices/commons/tags/axiom/ 5) If we go with short names (to match the jar files), we have a greater risk of collision with other project names, e.g., http://savannah.nongnu.org/projects/axiom So I look at all of these conflicting possibilities, and I think we need to come to some consensus about what to do here. I considered posting this to the packaging list, but I think it's a fairly java-centric problem at this point. Feel free to report on that list if you believe it's appropriate, though. (And if this topic has already been beaten to death, I apologize. I couldn't find a documented resolution, though.) Thanks. --Andy

5 22

New packaging macros and related things
by Stanislav Ochotnicky 16 Feb '12

16 Feb '12

Yesterday I pushed a new package into rawhide: javapackages-tools. This used to be part of jpackage-utils initially, now we split it into separate package. This should make some things a bit more simple for me :-) Now to things which will likely interest Java packagers: * %add_maven_depamp now has default arguments. I.e.: %add_maven_depmap is now equivalent to %add_maven_depmap JPP-%{name}.pom %{name}.jar This will simplify the "default" use case. You can of course still use the "full" version. * New %create_javadoc_subpackage macro: If you put this at the end of %install section it will generate whole java subpackage including file section etc. Please see /etc/rpm/macros.fjava for documentation on using it. There are 3 variables that change its behaviour a bit. Again, for simple maven modules/libraries this should simplify spec files I also have an idea that if implemented would completely remove need to specify add_maven_depmap in the spec file for simple use cases. We'll see how that works out when I have time to play with it. Alex Kurtakov also enabled OSGI Requires generator in this release so expect some interesting simplifications there as well. I expect Alex will comment on this point. -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

1 0

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

New java-1.6.0-openjdk needs for your test and vote
by Jiri Vanek 15 Feb '12

15 Feb '12

New java-1.6.0-openjd build upon latest (security) release of Icedtea6 is awaiting for your test and vote! https://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-63.1.10.… https://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-65.1.11.… Thank you in advance, Your friendly neighbourhood packager J.

1 0

using systemPath in POM files
by Andy Grimm 13 Feb '12

13 Feb '12

Hello, fellow java packagers. Little by little, I'm learning ways to make life with maven a little easier. One of the things I recently learned the quickest way to deal with a missing pom file. I was packaging wss4j, which depends on axis, which doesn't have a pom file in Fedora. I worked around it with this: <dependency> <groupId>org.apache.axis</groupId> <artifactId>axis</artifactId> <version>${axis.version}</version> - <scope>provided</scope> + <scope>system</scope> + <systemPath>${axis.basedir}/axis.jar</systemPath> </dependency> <dependency> (where axis.basedir is set to /usr/share/java/axis). The solution works fine, but is this acceptable? Is there a negative impact? It seems my only other alternative would be to file a bug and wait for the maintainer to add a pom to the axis package, and I'd rather not do that. (I'm happy to file the bug, but not to wait for the fix). Thanks, Andy

2 1

Packaging apache-mina and apache-sshd
by juan.hernandez＠redhat.com 09 Feb '12

09 Feb '12

Hello, As part of the effort to package oVirt for Fedora I need to package apache-mina and apache-sshd: http://mina.apache.org/ http://mina.apache.org/sshd As there is not indication in bugzilla that this has been done before I am starting to do it. Let me know if you have any suggestions. Regards, Juan Hernandez

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel February 2012