java-devel June 2008

java-devel@lists.fedoraproject.org

19 participants
15 discussions

packaging lessons from FUDCon hackfest?
by Karsten Wade 07 Jul '08

07 Jul '08

Andrew Overholt and Tom Fitzsimmons sat with a guy from Alfresco (Lee Faus) last Friday in the FUDCon hackfests. Mainly they were doing a code review with him to see what he has to do to get Alfresco packaged for Fedora. It was a great effort, and possibly enlightening for everyone as to the scope of the problem ahead of us to get Java ISVs packaged in Fedora. Andrew, Tom -- where there any insights, lessons, ideas, or other outfalls from that work with Lee? Two specific areas of interest are: * Tips, ideas, or plans for Java packaging ==> target wiki/Packaging/Java * ISV-specific lessons, tips, etc. ==> target wiki/SIGs/ISV I'm asking on this list because I think a brain dump from both of you here would give good exposure. I'm ready to glean content to make the above wiki updates. :) - Karsten -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41

5 7

Re: Ownership of /etc/maven/fragments and /usr/share/maven2/poms
by Deepak Bhole 30 Jun '08

30 Jun '08

* Jason L Tibbitts III <tibbs(a)math.uh.edu> [2008-06-28 18:23]: > Sorry for the resend; this should have the correct address for the > java list. > > I hope I'm CC'ing this sufficiently; I do not know if any > representatives form the Java group are members of fedora-packaging. > > I was reviewing my first maven-using package and ran into an issue > with the Java packaging guidelines. Namely that they specify that > every maven-using package should own /etc/maven/fragments and > /usr/share/maven2/poms, which contradicts our usual policy on > directory ownership by multiple packages. > > I don't really understand why the packages would need to own those > directories; jpackage-utils already serves as a kind of filesystem > package for java, it already owns /etc/maven and several > java-related directories in /usr/share, and all of the packages which > would own files in the two directories at issue already depend on it. > So I think jpackage-utils should just own /etc/maven/fragments and > /usr/share/maven2/poms and we can tweak the guidelines to not specify > that the individual packages own these directory. > > Another possibility would be to shift this off to a java-filesystem > package analogous to our other *-filesystem packages which could own > these and various other java directories. > I think moving them to jpackage-utils would be sufficient, as it owns a multitude of other java related directories right now. I have put this down on my TODO list and will get to it on Monday (off today and tomorrow). > This would fix ownership issues for 22 packages currently. > > Another separate bug related issue is the fact that the contents of > /etc/maven/fragments do not seem to be configuration files, and so > probably should not live under /etc. I do not have sufficient Java > knowledge to propose a solution, however. > Correct, technically they are not configuration related files. I'd be happy to move them, but I am not sure what the best place for them is either :/ .. suggestions are welcome. The files serve as configuration in the sense that they provide maven with a "mapping" between where maven expects jars to be, and where they actually are on the system. Cheers, Deepak

2 2

[mjj29@debian.org: Re: Developing with Java on Debian]
by Andrew Overholt 30 Jun '08

30 Jun '08

Has anyone from JPackage or Fedora spoken with the Debian java people? ----- Forwarded message from Matthew Johnson <mjj29(a)debian.org> ----- > From: Matthew Johnson <mjj29(a)debian.org> > To: Florian Grandel <jerico.dev(a)gmail.com> > Cc: debian-java(a)lists.debian.org > User-Agent: Mutt/1.5.17 (2007-11-01) > Date: Mon, 30 Jun 2008 14:26:45 +0100 > Subject: Re: Developing with Java on Debian > X-Mailing-List: <debian-java(a)lists.debian.org> archive/latest/9812 > > On Mon Jun 30 10:01, Florian Grandel wrote: > > Hi Java developers, > > > >> One problem that I haven't solved so far is how to get the classpath > >> into the MANIFEST file as was proposed earlier in this thread. > > > > As you may have remarked from my earlier posts I am working with the > > JPackage guys recently. Their "recommendation to Java developers" arguments > > against adding classpaths to the manifest. > > Well, they are wrong. > > > Probably the first three arguments do not apply to the Debian > > environment, but the last one may. I have not yet made up my mind on > > that. I just didn't want you to loose their arguments: > > > "Do not use Class-Path references in MANIFESTs > > > > The Class-Path system of MANIFESTs is evil because: > > > > * It doesn't work with JDK 1.x. > > * It only works at runtime, not at build time. > > * It only works for a specific installation hierarchy. > > These are, as you say, not relevant for Debian. I particularly like the > second point, since their solution of wrapper scripts means maintaining > two lists of classpath, one in the build system and one in the wrapper > _anyway_. The specific installation heirarchy thing is interesting. The > wrapper script is going to have to have _some_ guess at the heirarchy > and if that doesn't work you are just pushing the problem of creating > the classpath onto the user, which is clearly bad. > > Sufficiently clever build systems should propagate the build CLASSPATH > to the manifest automatically anyway. > > > * It can not be configured. > > It's unclear to me what they want to be configured at runtime by > changing the classpath. > > > Wrapper scripts are much versatile and universal. We provide a set of > > convenient shell helper functions for setting up such Unix scripts easily > > (see jpackage-utils in project CVS)." [1] > > Wrapper scripts without classpath manifest items also result in > large classpaths containing items you shouldn't have to know about (your > dependencies' dependencies) and causes unnecessary transitions when > these change. > > > You may also have a look at their build support system as they have some > > quite useful helper scripts as well. jpackage-utils is available in > > universe/contrib. > > But not available in Debian. > > > And as Richard was asking earlier how to identify dependencies within jar > > packages: I am using Matthew's java-propose-classpath a lot and it works > > fine (Thank you Matthew!). But sometimes it seems to miss some > > dependencies, I have not yet found out why. > > Hmm, if you can give me a test case, I'd be very interested. It > _should_ only suffer from giving you too many dependencies when there > are multiple jars containing the same class. > > Matt > -- > Matthew Johnson ----- End forwarded message -----

1 0

Re: /usr/share/eclipse/* -> %{_libdir}/eclipse/
by Andrew Overholt 30 Jun '08

30 Jun '08

* Nicolas Mailhot <nicolas.mailhot(a)laposte.net> [2008-06-27 15:17]: > Le vendredi 27 juin 2008 à 14:14 -0400, Andrew Overholt a écrit : > > > Does anyone have any thoughts on this? > > I'd rather you worked with Fernando Nasser and the other guys in > Fedora's java place on common jar deployment rules, instead of > reinventing the private app root dead-end that makes sharing resources > next to impossible and encourages library forking and duplication The JARs are 99% application-specific so putting them into a subdirectory makes sense to me and follows the guidelines we have in place. We have no library forking or duplication of the dependent JARs, either. Andrew

2 1

/usr/share/eclipse/* -> %{_libdir}/eclipse/
by Andrew Overholt 27 Jun '08

27 Jun '08

Hi, In the past we've struggled with multilib issues in the Eclipse SDK package. Examples include having to re-pack every JAR to have a common timestamp, shuffling arch-specific JARs off to %{_libdir} thus causing headaches with upstream mechanisms (which I'm concerned will continue with the new version), etc. I just found out today that Debian ships everything in %{_libdir}/eclipse to avoid these issues. I'm proposing we do the same for Fedora 10 and beyond. Pros: - self-contained installation like upstream - dramatically speeds up builds - remove potential for bugs with the multiple locations - looks like an upstream download - consistency with other distributions Cons: - larger disk footprint for multilib installations (on the order of 100 MB ... although the vast majority of users don't use both) Does anyone have any thoughts on this? Thanks, Andrew

1 0

Eclipse plugins outside the Fedora effort
by Mat Booth 23 Jun '08

23 Jun '08

Hi all, There's been question asked on one of my bugs[1] that I'm not confident I know the answer to. Essentially, he's asking what the policy is on using Eclipse plugins that are outside the Fedora effort. I don't know of any formal documentation and my gut feeling is that everything should just work, if you don't mind extra the configuration because of the lack of really tight integration that comes with Fedora packaged plugins. But I'm still new to Fedora as a contributor so I though I'd garner a second opinion to make sure I'm not lying my arse off. Any thoughts? Regards, Mat [1] https://bugzilla.redhat.com/show_bug.cgi?id=452442#c2 -- Mat Booth www.matbooth.co.uk

2 1

bug 452045 -- RSSOwl broken with Fedora
by Matej Cepl 23 Jun '08

23 Jun '08

Hi, guys, fast question from the other part of the desktop team -- any ideas what's going on with bug 452045? Apparently Martin Stransky (from the firefox side) has no idea what could be wrong, and somebody on #rssowl suggested that https://bugs.eclipse.org/bugs/show_bug.cgi?id=236724 may be related. Thanks for any reply, Matej

2 1

Eclipse-epic build fails on ppc and ppc64 for F8 and F10
by Mat Booth 16 Jun '08

16 Jun '08

Updating my packages today I'm finding that Java is crashing when building eclipse-epic on ppc/ppc64 on F8 and F10 with: *** glibc detected *** java: free(): invalid next size (normal): 0x10113540 *** F10 ppc stack trace: http://koji.fedoraproject.org/koji/getfile?taskID=661999&name=build.log F8 ppc64 stack trace: http://koji.fedoraproject.org/koji/getfile?taskID=661990&name=build.log Strangely, it worked fine on F9. Is this a known bug? -- Mat Booth www.matbooth.co.uk

3 3

compatible provides?
by Benjamin Reed 13 Jun '08

13 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Would it be possible to add compatible provides to the openjdk -devel package? Since OpenNMS uses Tomcat and/or Jetty, and does not precompile it's JSP files, we require a JDK at runtime. Unfortunately, there are no provides that are the same across OpenJDK and Sun's Java: Sun JDK: [ranger@nen ~]$ rpm -q --provides jdk jre = 1.5.0_15 j2sdk = 1.5.0_15 j2re = 1.5.0_15 jaxp_parser_impl xml-commons-apis jdk = 2000:1.5.0_15-fcs jaxp_parser_impl xml-commons-apis jdk = 2000:1.6.0_05-fcs OpenJDK: [ranger@localhost opennms-1.6]$ rpm -q --provides \ ~ java-1.6.0-openjdk-devel java-1.6.0-devel = 1:1.6.0.0 java-1.7.0-icedtea-devel = 0:1.7.0.0-0.999 java-devel = 1:1.6.0 java-devel-openjdk = 1:1.6.0.0 java-sdk = 1:1.6.0 java-sdk-1.6.0 = 1:1.6.0.0 java-sdk-1.6.0-openjdk = 1:1.6.0.0 java-sdk-openjdk = 1:1.6.0.0 lib.so libunpack.so java-1.6.0-openjdk-devel = 1:1.6.0.0-0.13.b09.fc9 - -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITZstUu+jZtP2Zf4RAn2lAKCBTG40bO7w0rC/8tPSmegwZFoJ5wCeIMUC 04m2D8MnA0EGEfQdYn5zPxM= =dayB -----END PGP SIGNATURE-----

4 8

ant possibly broken when using 'ant generate.wsdl' from axis2 examples
by Timothy Selivanow 11 Jun '08

11 Jun '08

Hi, I'm going through the quickstart sample from axis2 and found an error that only occurs while using the packaged ant in Fedora 8 and 9. Here is the error I receive: $ ant generate.wsdl Buildfile: build.xml compile.service: generate.wsdl: BUILD FAILED /home/timothys/projects/lib/java/axis2-1.4/samples/quickstart/build.xml:53: java.lang.ExceptionInInitializerError Total time: 0 seconds When run with '-debug', I see *lots* of the following errors: Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. When I use upstream's ant and set ANT_HOME to that, the error does not occur and the build succeeds. I'm very new to java et al., so I don't know if I am missing something, or if this is a bug in the way things are packaged... --Tim

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel June 2008