From overholt at redhat.com Wed Oct 1 16:30:47 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 1 Oct 2008 12:30:47 -0400 Subject: [fedora-java] Maintainer wanted for Eclipse Graphical Editing Framework (GEF ... eclipse-gef) Message-ID: <20081001163046.GB14391@redhat.com> Hi, Does anyone want to maintain GEF? I don't have time for it and haven't updated it recently. It needs to be updated to the latest (Ganymede train) release. Nothing depends upon it so if no one wants it and we remove it it's probably not the end of the world. I've given up ownership in FAS so feel free to take it there if you want it. Andrew From fedora at matbooth.co.uk Wed Oct 1 17:59:52 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Wed, 1 Oct 2008 18:59:52 +0100 Subject: [fedora-java] Re: Maintainer wanted for Eclipse Graphical Editing Framework (GEF ... eclipse-gef) In-Reply-To: <20081001163046.GB14391@redhat.com> References: <20081001163046.GB14391@redhat.com> Message-ID: <9497e9990810011059j23fb6237p635cf242d37c13aa@mail.gmail.com> On Wed, Oct 1, 2008 at 5:30 PM, Andrew Overholt wrote: > Hi, > > Does anyone want to maintain GEF? I don't have time for it and haven't > updated it recently. It needs to be updated to the latest (Ganymede > train) release. Nothing depends upon it so if no one wants it and we > remove it it's probably not the end of the world. > > I've given up ownership in FAS so feel free to take it there if you want > it. > > Andrew > I'd be willing to take this since I'd like to eventually get the Data Tools into Fedora. This is one of the prerequisites. Regards, Mat -- Mat Booth www.matbooth.co.uk From orcanbahri at yahoo.com Thu Oct 2 05:44:36 2008 From: orcanbahri at yahoo.com (Orcan Ogetbil) Date: Wed, 1 Oct 2008 22:44:36 -0700 (PDT) Subject: [fedora-java] iText status? In-Reply-To: <20080930124631.GC3466@redhat.com> Message-ID: <597583.16563.qm@web32803.mail.mud.yahoo.com> --- On Tue, 9/30/08, Andrew Overholt wrote: > From: Andrew Overholt > Subject: Re: [fedora-java] iText status? > To: "Orcan Ogetbil" > Cc: fedora-devel-java-list at redhat.com > Date: Tuesday, September 30, 2008, 8:46 AM > Hi Orcan, > > * Orcan Ogetbil [2008-09-30 > 01:35]: > > What is the current status of iText on Fedora? Was > there a discussion? > > Can we consider releasing it again? > > I'm not sure that anyone's looked at it since the > original problem. If > you'd like to take the lead on figuring out the > legalities and working > with Fedora Legal, it would be much appreciated. > > Andrew I have contacted Fedora-legal and they told me that they will audit the issue when the package hits to bugzilla. I compiled itext today. It has some dependencies (bouncycastle) that need to be upgraded in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=465203 This may take a while, depending on its packager. There is also a new dependency that itext depends on [1]. Hence we will need to wait a little longer for itext. oget [1] bcmail, which can be packaged together with bouncycastle's bcprov, or maybe as a sub-package. From orcanbahri at yahoo.com Fri Oct 3 18:15:50 2008 From: orcanbahri at yahoo.com (Orcan Ogetbil) Date: Fri, 3 Oct 2008 11:15:50 -0700 (PDT) Subject: [fedora-java] iText status? In-Reply-To: <20080930124631.GC3466@redhat.com> Message-ID: <271951.69743.qm@web32807.mail.mud.yahoo.com> --- On Tue, 9/30/08, Andrew Overholt wrote: > From: Andrew Overholt > Subject: Re: [fedora-java] iText status? > To: "Orcan Ogetbil" > Cc: fedora-devel-java-list at redhat.com > Date: Tuesday, September 30, 2008, 8:46 AM > Hi Orcan, > > * Orcan Ogetbil [2008-09-30 > 01:35]: > > What is the current status of iText on Fedora? Was > there a discussion? > > Can we consider releasing it again? > > I'm not sure that anyone's looked at it since the > original problem. If > you'd like to take the lead on figuring out the > legalities and working > with Fedora Legal, it would be much appreciated. > > Andrew I packaged itext. The bugzilla report can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=465511 I also sent an email to fedora-legal; they will audit the process. Cheers, oget From scofield1nr at gmail.com Wed Oct 8 17:11:15 2008 From: scofield1nr at gmail.com (nabil en_nouini) Date: Wed, 8 Oct 2008 17:11:15 +0000 Subject: [fedora-java] Service Message-ID: if someone have a doc for installing freeradius and authentification with MAC adress;send it to me plz -- La richesse et le prestige acquis au cours de la vie terrestre n y ont aucune valeur ,seule la bonne qualit? d'ame & l'habitude de justice qui decident de la destination des morts.... Il faut lui permettre la satire et la plainte : la haine renferm?e est plus dangereuse que la haine ouverte.(Denis diderot) @@@@@@@@@@@@@@@@@@@ + Nabil EN_NOUINI + +tel : 074043384+ + Info 2008+ ??????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca at foppiano.org Thu Oct 9 11:05:10 2008 From: luca at foppiano.org (Luca Foppiano) Date: Thu, 09 Oct 2008 13:05:10 +0200 Subject: [fedora-java] groovy compilation - maven problem. Message-ID: <1223550310.3979.26.camel@sboing.byte-code.lan> Hi, I've a problem while compiling groovy using maven. I run mvn-jpp compile, but I got this error: [lfoppiano at sboing apache-tomcat-5.5.27-src]$ mvn-jpp compile /etc/alternatives/java_sdk [INFO] Scanning for projects... [INFO] ---------------------------------------------------------------------------- [INFO] Building Maven Default Project [INFO] task-segment: [compile] [INFO] ---------------------------------------------------------------------------- [WARNING] Skipping non filebased repository http://repo1.maven.org/maven2 in full offline mode [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-resources-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-resources-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-resources-plugin:pom:2.2 from the specified remote repositories: __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) [INFO] ------------------------------------------------------------------------ [....] but I don't understand why it doesn't work...I have installed these packages: [lfoppiano at sboing apache-tomcat-5.5.27-src]$ yum list installed maven2-plugin* Loaded plugins: fastestmirror, presto, refresh-packagekit Installed Packages maven2-plugin-antrun.x86_64 2.0.4-10jpp.10.fc9 installed maven2-plugin-clean.x86_64 2.0.4-10jpp.10.fc9 installed maven2-plugin-compiler.x86_64 2.0.4-10jpp.10.fc9 installed maven2-plugin-install.x86_64 2.0.4-10jpp.10.fc9 installed maven2-plugin-jar.x86_64 2.0.4-10jpp.10.fc9 installed maven2-plugin-javadoc.x86_64 2.0.4-10jpp.10.fc9 installed maven2-plugin-plugin.x86_64 2.0.4-10jpp.10.fc9 installed maven2-plugin-resources.x86_64 2.0.4-10jpp.10.fc9 installed maven2-plugin-surefire.x86_64 2.0.4-10jpp.10.fc9 installed that error is strange... anyone have idea about it? thanks Luca -- Today is Boomtime, the 63rd day of Bureaucracy in the YOLD 3174 I came, I saw, I deleted all your files. From david at zarb.org Wed Oct 15 17:33:17 2008 From: david at zarb.org (David Walluck) Date: Wed, 15 Oct 2008 13:33:17 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 Message-ID: <48F6295D.8000303@zarb.org> I was asked to make sure that tanukiwrapper and libreadline-java were up to date for F10. What I found is that there is no consistent policy for either .so location or .jar location for Java packages in Fedora. Here are some examples: Library location: eclipse: /usr/lib64/eclipse jss: /usr/lib64 libreadline-java: /usr/lib64/libreadline-java tanukiwrapper: /usr/lib64 Jar location: eclipse: /usr/lib64/java jss: /usr/lib/java libreadline-java: /usr/lib64/libreadline-java tanukiwrapper: /usr/share/java I believe that libreadline-java was meant to be the model for the JNI policy, but the problem is that jpackage-utils (build-classpath) does not seem to be updated to work with the new jar location. NB: I tested on F9, so if this has changed, let me know. We have very little time to do anything about this before the F10 freeze, so I suggest we take the path of least-resistance, e.g., we have to move libreadline-java back since we would not be able to update all the packages and the tools and make sure that they work in time for F10. -- Sincerely, David Walluck From fitzsim at fitzsim.org Wed Oct 15 18:10:25 2008 From: fitzsim at fitzsim.org (Thomas Fitzsimmons) Date: Wed, 15 Oct 2008 11:10:25 -0700 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48F6295D.8000303@zarb.org> (David Walluck's message of "Wed, 15 Oct 2008 13:33:17 -0400") References: <48F6295D.8000303@zarb.org> Message-ID: David Walluck writes: > I was asked to make sure that tanukiwrapper and libreadline-java were > up to date for F10. > > What I found is that there is no consistent policy for either .so > location or .jar location for Java packages in Fedora. There is a policy: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI but some existing packages may not follow it. > Here are some examples: > > Library location: > > eclipse: /usr/lib64/eclipse Eclipse is a special case. Andrew Overholt can comment on this. > jss: /usr/lib64 > libreadline-java: /usr/lib64/libreadline-java > tanukiwrapper: /usr/lib64 > > Jar location: > > eclipse: /usr/lib64/java > jss: /usr/lib/java > libreadline-java: /usr/lib64/libreadline-java > tanukiwrapper: /usr/share/java Ideally jss and tanukiwrapper would be updated to follow the packaging guidelines. > I believe that libreadline-java was meant to be the model for the JNI > policy, but the problem is that jpackage-utils (build-classpath) does > not seem to be updated to work with the new jar location. What is the symptom of this problem? > NB: I tested on F9, so if this has changed, let me know. > > We have very little time to do anything about this before the F10 > freeze, so I suggest we take the path of least-resistance, e.g., we > have to move libreadline-java back I'm not sure what you mean by this. > since we would not be able to update all the packages and the tools > and make sure that they work in time for F10. Tom From overholt at redhat.com Wed Oct 15 18:11:18 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 15 Oct 2008 14:11:18 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48F6295D.8000303@zarb.org> References: <48F6295D.8000303@zarb.org> Message-ID: <20081015181116.GA15145@redhat.com> * David Walluck [2008-10-15 13:33]: > What I found is that there is no consistent policy for either .so > location or .jar location for Java packages in Fedora. Here are some > examples: The guidelines have locations. http://fedoraproject.org/wiki/Packaging/Java#Directory_structure http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI Perhaps the packages you were looking at just didn't meet the guidelines (I will say that Eclipse doesn't count since it's not a "regular" java app in that its plugin jars -- and few .sos -- aren't really/easily usable by other java apps). Andrew From david at zarb.org Wed Oct 15 18:14:39 2008 From: david at zarb.org (David Walluck) Date: Wed, 15 Oct 2008 14:14:39 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: References: <48F6295D.8000303@zarb.org> Message-ID: <48F6330F.5030206@zarb.org> Thomas Fitzsimmons wrote: > What is the symptom of this problem? If each jar is to be stored in its own directory, then build-classpath and build-jar-repository need to be updated to be able to find these jar locations. Otherwise, we just just get $ build-classpath libreadline-java /usr/bin/build-classpath: error: Could not find libreadline-java Java extension for this JVM /usr/bin/build-classpath: error: Some specified jars were not found The other issue is that someone has to be willing to find and update all JNI packages to the new policy. I am not sure whye clipse should be a special case. There are quite a few desktop applications (tuxguitar, vuze) that could make use of swt. -- Sincerely, David Walluck From overholt at redhat.com Wed Oct 15 18:35:03 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 15 Oct 2008 14:35:03 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48F6330F.5030206@zarb.org> References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> Message-ID: <20081015183502.GB15145@redhat.com> * David Walluck [2008-10-15 14:15]: > I am not sure whye clipse should be a special case. There are quite a > few desktop applications (tuxguitar, vuze) that could make use of swt. We put symlinks to the SWT bundle in places that build-classpath can find it. The rest of the Eclipse bundles are arguably useless outside of an OSGi environment. Andrew From fitzsim at fitzsim.org Wed Oct 15 20:33:26 2008 From: fitzsim at fitzsim.org (Thomas Fitzsimmons) Date: Wed, 15 Oct 2008 13:33:26 -0700 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48F6330F.5030206@zarb.org> (David Walluck's message of "Wed, 15 Oct 2008 14:14:39 -0400") References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> Message-ID: David Walluck writes: > Thomas Fitzsimmons wrote: >> What is the symptom of this problem? > > If each jar is to be stored in its own directory, then build-classpath > and build-jar-repository need to be updated to be able to find these > jar locations. Otherwise, we just just get > > $ build-classpath libreadline-java > /usr/bin/build-classpath: error: Could not find libreadline-java Java > extension for this JVM > > /usr/bin/build-classpath: error: Some specified jars were not found OK, which packages are these errors affecting? You could add the libreadline-java jar to CLASSPATH after the build-classpath invocation. In any case I don't think you should change libreadline-java to not follow the packaging guidelines, if that's what you were planning. Tom From david at zarb.org Wed Oct 15 20:43:06 2008 From: david at zarb.org (David Walluck) Date: Wed, 15 Oct 2008 16:43:06 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> Message-ID: <48F655DA.4050304@zarb.org> Thomas Fitzsimmons wrote: > OK, which packages are these errors affecting? You could add the > libreadline-java jar to CLASSPATH after the build-classpath invocation. Only libreadline-java is affected right now since that's the only package that I found adhering to the policy. So far, all the packages fail in one of two ways: either the package doesn't work with build-classpath, or it doesn't adhere to the policy. > In any case I don't think you should change libreadline-java to not > follow the packaging guidelines, if that's what you were planning. I would tend to agree, but the tools have not been updated to support this configuration. The choice seems to be to change either the tools or any of the packages to conform to the packaging guidelines. As it stands now, I am more concerned with breaking existing build-classpath invocations then following the policy since F10 is almost frozen and nothing is consistent. Left as-is, you will just get four packages with four different policies, and some of these may break existing builds or scripts. -- Sincerely, David Walluck From jmrodri at gmail.com Wed Oct 15 20:49:22 2008 From: jmrodri at gmail.com (Jesus M. Rodriguez) Date: Wed, 15 Oct 2008 16:49:22 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48F655DA.4050304@zarb.org> References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> <48F655DA.4050304@zarb.org> Message-ID: On Wed, Oct 15, 2008 at 4:43 PM, David Walluck wrote: > Thomas Fitzsimmons wrote: >> >> OK, which packages are these errors affecting? You could add the >> libreadline-java jar to CLASSPATH after the build-classpath invocation. > > Only libreadline-java is affected right now since that's the only package > that I found adhering to the policy. > > So far, all the packages fail in one of two ways: either the package doesn't > work with build-classpath, or it doesn't adhere to the policy. > >> In any case I don't think you should change libreadline-java to not >> follow the packaging guidelines, if that's what you were planning. > > I would tend to agree, but the tools have not been updated to support this > configuration. The choice seems to be to change either the tools or any of > the packages to conform to the packaging guidelines. > > As it stands now, I am more concerned with breaking existing build-classpath > invocations then following the policy since F10 is almost frozen and nothing > is consistent. > > Left as-is, you will just get four packages with four different policies, > and some of these may break existing builds or scripts. > > -- > Sincerely, > > David Walluck > > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > As a consumer of these packages, particularly tanukiwrapper, I prefer the jar lives in /usr/share/java/ and the JNI library live in /usr/lib(64). It's nice to know where ALL of the jar files live. Having to determine if a jar is native or not and determine whether to look in /usr/lib, /usr/lib64, or /usr/share/java seems a bit annoying. If you look at it from the java side, a developer will put the jar file with all of their other jars. Then put the library in the platform specific location. So putting the jars in /usr/share/java really fits inline with this. Sorry, just offering my 2 cents as a user :) /me didn't realize there was already policy to do the contrary, I would've spoke up then. Sincerely, jesus rodriguez From overholt at redhat.com Wed Oct 15 20:50:04 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 15 Oct 2008 16:50:04 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> <48F655DA.4050304@zarb.org> Message-ID: <20081015205004.GH15145@redhat.com> * Jesus M. Rodriguez [2008-10-15 16:50]: > As a consumer of these packages, particularly tanukiwrapper, I prefer > the jar lives in /usr/share/java/ and the > JNI library live in /usr/lib(64). As long as the JAR doesn't contain native code ... Andrew From fedora at matbooth.co.uk Sun Oct 19 10:45:19 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Sun, 19 Oct 2008 11:45:19 +0100 Subject: [fedora-java] Eclipse/GCJ support Message-ID: <9497e9990810190345v5a1cd839p1ec15d4eacccccb9@mail.gmail.com> >From looking at the rawhide reports, it looks like eclipse-pydev, eclipse-rpm-editor and eclipse-quickrex have all just dropped support for gcj compilation. Are we not following that guideline for eclipse plugins anymore? If not, we should update http://fedoraproject.org/wiki/Packaging/EclipsePlugins Regards, Mat -- Mat Booth www.matbooth.co.uk From overholt at redhat.com Sun Oct 19 22:45:45 2008 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 19 Oct 2008 18:45:45 -0400 Subject: [fedora-java] Eclipse/GCJ support In-Reply-To: <9497e9990810190345v5a1cd839p1ec15d4eacccccb9@mail.gmail.com> References: <9497e9990810190345v5a1cd839p1ec15d4eacccccb9@mail.gmail.com> Message-ID: <20081019224544.GA6787@redhat.com> * Mat Booth [2008-10-19 06:46]: > Are we not following that guideline for eclipse plugins anymore? If > not, we should update > http://fedoraproject.org/wiki/Packaging/EclipsePlugins The guidelines always just said "follow the GCJ guidelines" which just say "do it if you want to" so it's up to the individual packager. I suppose we should have a broader discussion about GCJ post-F10 (I think that's what we said we'd do pre-F9). Andrew From fnasser at redhat.com Tue Oct 21 19:46:38 2008 From: fnasser at redhat.com (Fernando Nasser) Date: Tue, 21 Oct 2008 15:46:38 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48F655DA.4050304@zarb.org> References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> <48F655DA.4050304@zarb.org> Message-ID: <48FE319E.9050005@redhat.com> Can't we have the real JAR and the .so in %{_libdir}/%{name} as required by the guideline and add a symlink to the JAR (only) in /usr/share/java ? P.S.: This will get worse with the increase of maven use by projects as it is more strict where the dependency "artifacts" are located. You could perhaps change build-classpath to look at other places but it will e harder with maven. David Walluck wrote: > Thomas Fitzsimmons wrote: >> OK, which packages are these errors affecting? You could add the >> libreadline-java jar to CLASSPATH after the build-classpath invocation. > > Only libreadline-java is affected right now since that's the only > package that I found adhering to the policy. > > So far, all the packages fail in one of two ways: either the package > doesn't work with build-classpath, or it doesn't adhere to the policy. > >> In any case I don't think you should change libreadline-java to not >> follow the packaging guidelines, if that's what you were planning. > > I would tend to agree, but the tools have not been updated to support > this configuration. The choice seems to be to change either the tools or > any of the packages to conform to the packaging guidelines. > > As it stands now, I am more concerned with breaking existing > build-classpath invocations then following the policy since F10 is > almost frozen and nothing is consistent. > > Left as-is, you will just get four packages with four different > policies, and some of these may break existing builds or scripts. > From david at zarb.org Tue Oct 21 20:01:10 2008 From: david at zarb.org (David Walluck) Date: Tue, 21 Oct 2008 16:01:10 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48FE319E.9050005@redhat.com> References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> <48F655DA.4050304@zarb.org> <48FE319E.9050005@redhat.com> Message-ID: <48FE3506.7090801@zarb.org> Fernando Nasser wrote: > Can't we have the real JAR and the .so in %{_libdir}/%{name} as required > by the guideline and add a symlink to the JAR (only) in /usr/share/java ? JPackage already provides a location for these jars, and this location is searched by jpackage-utils. The location is %_jnidir, and it seems to be defined as %_prefix/lib/java, but it should probably be %_libdir/java. Contrast this with Debian which palces .so in /usr/lib/jni and the jar in /usr/share/java. If JNI using JAR files are really not arch-specific, they should go in %_javadir. I do not see why the Fedora guidelines place jars in application-specific directories with the shared library itself. There are two issues: 1.) No one (Debian, Fedora, JPackage) can agree on the .jar location: (i.) %_prefix/lib/java (ii.) %_libdir/java (iii.) %_javadir (iv.) %_libdir/%name. 2.) If the .jar location is only (iv.) %_libdir/%name as in the Fedora guidelines (no symlinks), then any specs or scripts that use build-classpath on these jars would need to be re-written, and it is not clear why they behave differently from all other jars in this way. And the JPackage specs and scripts automatically become incompatible. -- Sincerely, David Walluck From akurtako at redhat.com Tue Oct 21 20:47:02 2008 From: akurtako at redhat.com (Alexander Kurtakov) Date: Tue, 21 Oct 2008 22:47:02 +0200 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48FE3506.7090801@zarb.org> References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> <48F655DA.4050304@zarb.org> <48FE319E.9050005@redhat.com> <48FE3506.7090801@zarb.org> Message-ID: <48FE3FC6.4070105@redhat.com> David Walluck wrote: > Fernando Nasser wrote: >> Can't we have the real JAR and the .so in %{_libdir}/%{name} as >> required by the guideline and add a symlink to the JAR (only) in >> /usr/share/java ? > > JPackage already provides a location for these jars, and this location > is searched by jpackage-utils. The location is %_jnidir, and it seems > to be defined as %_prefix/lib/java, but it should probably be > %_libdir/java. > > Contrast this with Debian which palces .so in /usr/lib/jni and the jar > in /usr/share/java. > > If JNI using JAR files are really not arch-specific, they should go in > %_javadir. I do not see why the Fedora guidelines place jars in > application-specific directories with the shared library itself. > > There are two issues: > > 1.) No one (Debian, Fedora, JPackage) can agree on the .jar location: > (i.) %_prefix/lib/java (ii.) %_libdir/java (iii.) %_javadir (iv.) > %_libdir/%name. > > 2.) If the .jar location is only (iv.) %_libdir/%name as in the Fedora > guidelines (no symlinks), then any specs or scripts that use > build-classpath on these jars would need to be re-written, and it is > not clear why they behave differently from all other jars in this way. > > And the JPackage specs and scripts automatically become incompatible. > Breaking compatibility with jpackage just for the change is stupid - at least I don't see any benefit. Breaking compatibility with nomatter what should bring some benefits otherwise we are doing work which bring us only more work and less features. This also makes things harder for most packagers for several users: 1. Jpackage guidelines and tools are well known - most of the experienced packagers in the java area either have been part of the jpackage once are part now or at least are familiar with them. And I'm not speaking for Fedora guys only. 2. We make our specs harder to maintain - Using build-classpath frees you from details like whether the jar has native parts or not. But with the current policy - placing jars in %_libdir/%name if the jar adds some native parts you should change your spec file. Using build-classpath you just need to rebuild with no changes. But wait - there is even more you can use build-classpath in your startup shell files so you even don't need to rebuild. Please don't break compatibility with JPackage with some policy if you really don't have something much better. I completely support the following steps : 1. %_jnidir should be defined as %_libdir/java 2. All the jars with native parts should be installed in %_jnidir 3. jpackage-utils should be checked for needed modifications for this change. Best regards, Alexander Kurtakov From jmrodri at gmail.com Wed Oct 22 00:21:56 2008 From: jmrodri at gmail.com (Jesus M. Rodriguez) Date: Tue, 21 Oct 2008 20:21:56 -0400 Subject: [fedora-java] Mending the Java native library mess before F10 In-Reply-To: <48FE319E.9050005@redhat.com> References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> <48F655DA.4050304@zarb.org> <48FE319E.9050005@redhat.com> Message-ID: On Tue, Oct 21, 2008 at 3:46 PM, Fernando Nasser wrote: > Can't we have the real JAR and the .so in %{_libdir}/%{name} as required by > the guideline and add a symlink to the JAR (only) in /usr/share/java ? As a consumer of said libraries, I like this approach. > P.S.: This will get worse with the increase of maven use by projects as it > is more strict where the dependency "artifacts" are located. You could > perhaps change build-classpath to look at other places but it will e harder > with maven. Don't get me started on maven. :) jesus From fitzsim at fitzsim.org Wed Oct 22 01:00:04 2008 From: fitzsim at fitzsim.org (Thomas Fitzsimmons) Date: Tue, 21 Oct 2008 18:00:04 -0700 Subject: [fedora-java] Re: Mending the Java native library mess before F10 In-Reply-To: <48FE319E.9050005@redhat.com> (Fernando Nasser's message of "Tue, 21 Oct 2008 15:46:38 -0400") References: <48F6295D.8000303@zarb.org> <48F6330F.5030206@zarb.org> <48F655DA.4050304@zarb.org> <48FE319E.9050005@redhat.com> Message-ID: Fernando Nasser writes: > Can't we have the real JAR and the .so in %{_libdir}/%{name} as > required by the guideline and add a symlink to the JAR (only) in > /usr/share/java ? No, since this would cause ambiguity in the multilib case. Part of solving the arch-specific JAR problem is having the JPackage wrapper scripts resolve %{_libdir} based on whether the app will run on a 32-bit or 64-bit JVM. Tom > P.S.: This will get worse with the increase of maven use by projects > as it is more strict where the dependency "artifacts" are located. > You could perhaps change build-classpath to look at other places but > it will e harder with maven. > > David Walluck wrote: >> Thomas Fitzsimmons wrote: >>> OK, which packages are these errors affecting? You could add the >>> libreadline-java jar to CLASSPATH after the build-classpath invocation. >> >> Only libreadline-java is affected right now since that's the only >> package that I found adhering to the policy. >> >> So far, all the packages fail in one of two ways: either the package >> doesn't work with build-classpath, or it doesn't adhere to the >> policy. >> >>> In any case I don't think you should change libreadline-java to not >>> follow the packaging guidelines, if that's what you were planning. >> >> I would tend to agree, but the tools have not been updated to >> support this configuration. The choice seems to be to change either >> the tools or any of the packages to conform to the packaging >> guidelines. >> >> As it stands now, I am more concerned with breaking existing >> build-classpath invocations then following the policy since F10 is >> almost frozen and nothing is consistent. >> >> Left as-is, you will just get four packages with four different >> policies, and some of these may break existing builds or scripts. >> From aph at redhat.com Fri Oct 24 14:59:10 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Oct 2008 15:59:10 +0100 Subject: [fedora-java] Strange build error for classpathx-mail In-Reply-To: <48C19553.9050401@cora.nwra.com> References: <48C17F34.2010207@cora.nwra.com> <48C1811F.4090003@redhat.com> <48C19553.9050401@cora.nwra.com> Message-ID: <4901E2BE.8010003@redhat.com> Orion Poplawski wrote: > Andrew Haley wrote: >> >> This is probably https://bugzilla.redhat.com/show_bug.cgi?id=459129 >> >> Jakub has a patch and we're waiting for gcj to be respun into a new RPM. >> >> Andrew. > > Indeed. Thanks. This one seems to have resurfaced, and may not be the same bug. http://koji.fedoraproject.org/koji/getfile?taskID=898486&name=build.log Andrew. From lfarkas at lfarkas.org Mon Oct 27 12:00:54 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Mon, 27 Oct 2008 13:00:54 +0100 Subject: [fedora-java] gstreamer-java not compile on fedora ppc Message-ID: <4905AD76.8050909@lfarkas.org> hi, on fedora gstreamer-java not build on linux-ppc. the relevant build log is here, where you can see that the unit test fails on ppc: http://koji.fedoraproject.org/koji/getfile?taskID=905786&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=905792&name=build.log is there any tip what can be the reason? is it a gstreamer-java, jna or openjdk bug? thanks. -- Levente "Si vis pacem para bellum!" From gbenson at redhat.com Mon Oct 27 12:45:47 2008 From: gbenson at redhat.com (Gary Benson) Date: Mon, 27 Oct 2008 12:45:47 +0000 Subject: [fedora-java] gstreamer-java not compile on fedora ppc In-Reply-To: <4905AD76.8050909@lfarkas.org> References: <4905AD76.8050909@lfarkas.org> Message-ID: <20081027124546.GE3934@redhat.com> Farkas Levente wrote: > on fedora gstreamer-java not build on linux-ppc. the relevant build > log is here, where you can see that the unit test fails on ppc: > http://koji.fedoraproject.org/koji/getfile?taskID=905786&name=build.log > http://koji.fedoraproject.org/koji/getfile?taskID=905792&name=build.log > is there any tip what can be the reason? > is it a gstreamer-java, jna or openjdk bug? This looks like this: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=190 Cheers, Gary -- http://gbenson.net/ From aph at redhat.com Mon Oct 27 13:18:21 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Oct 2008 13:18:21 +0000 Subject: [fedora-java] gstreamer-java not compile on fedora ppc In-Reply-To: <20081027124546.GE3934@redhat.com> References: <4905AD76.8050909@lfarkas.org> <20081027124546.GE3934@redhat.com> Message-ID: <4905BF9D.2020005@redhat.com> Gary Benson wrote: > Farkas Levente wrote: >> on fedora gstreamer-java not build on linux-ppc. the relevant build >> log is here, where you can see that the unit test fails on ppc: >> http://koji.fedoraproject.org/koji/getfile?taskID=905786&name=build.log >> http://koji.fedoraproject.org/koji/getfile?taskID=905792&name=build.log >> is there any tip what can be the reason? >> is it a gstreamer-java, jna or openjdk bug? > > This looks like this: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=190 Ah, JSR 166 is something I'm very familiar with. I'll look. Andrew. From gbenson at redhat.com Mon Oct 27 13:19:54 2008 From: gbenson at redhat.com (Gary Benson) Date: Mon, 27 Oct 2008 13:19:54 +0000 Subject: [fedora-java] gstreamer-java not compile on fedora ppc In-Reply-To: <4905BF9D.2020005@redhat.com> References: <4905AD76.8050909@lfarkas.org> <20081027124546.GE3934@redhat.com> <4905BF9D.2020005@redhat.com> Message-ID: <20081027131953.GF3934@redhat.com> Andrew Haley wrote: > Gary Benson wrote: > > Farkas Levente wrote: > > > on fedora gstreamer-java not build on linux-ppc. the relevant build > > > log is here, where you can see that the unit test fails on ppc: > > > http://koji.fedoraproject.org/koji/getfile?taskID=905786&name=build.log > > > http://koji.fedoraproject.org/koji/getfile?taskID=905792&name=build.log > > > is there any tip what can be the reason? > > > is it a gstreamer-java, jna or openjdk bug? > > > > This looks like this: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=190 > > Ah, JSR 166 is something I'm very familiar with. I'll look. Excellent, thanks. Cheers, Gary -- http://gbenson.net/ From loganjerry at gmail.com Mon Oct 27 21:01:12 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 27 Oct 2008 15:01:12 -0600 Subject: [fedora-java] Fedora & JPackage Message-ID: <870180fe0810271401l7cb2b36qe654efd02a56d043@mail.gmail.com> A few months back, I had to start using a web service provided by a certain commercial content management system. This particular web service uses a namespace that is provided only by Apache Axis 1. At that time, I discovered that we are two versions behind on this dead product [1] (Apache Axis 2 is the version under active development). I started looking into what would be needed to get Apache Axis 2 into Fedora, and discovered a long list of missing dependencies and a long list of packages that would need to be upgraded. More recently, I took over the pmd package, and found that 3 other packages would need to be upgraded to move pmd to a newer version [2] [3] [4]. Both events made me wonder how much we are gaining by drawing spec files from JPackage, and how much we are losing. I wondered whether maintainers were not moving forward to newer versions of their packages because the JPackage versions were not moving forward. So I collected a little data on the subject. This is far from the final word; more information has to be collected to make any final determination. But I thought some of you might find what I have collected so far interesting. http://jjames.fedorapeople.org/java.html Comments welcome. Relevant bugs: [1] https://bugzilla.redhat.com/show_bug.cgi?id=231153 [2] https://bugzilla.redhat.com/show_bug.cgi?id=465985 [3] https://bugzilla.redhat.com/show_bug.cgi?id=465987 [4] https://bugzilla.redhat.com/show_bug.cgi?id=465989 -- Jerry James http://loganjerry.googlepages.com/ From david at zarb.org Mon Oct 27 21:45:38 2008 From: david at zarb.org (David Walluck) Date: Mon, 27 Oct 2008 17:45:38 -0400 Subject: [fedora-java] Fedora & JPackage In-Reply-To: <870180fe0810271401l7cb2b36qe654efd02a56d043@mail.gmail.com> References: <870180fe0810271401l7cb2b36qe654efd02a56d043@mail.gmail.com> Message-ID: <49063682.4030401@zarb.org> Jerry James wrote: > Both events made me wonder how much we are gaining by drawing spec > files from JPackage, and how much we are losing. I wondered whether > maintainers were not moving forward to newer versions of their > packages because the JPackage versions were not moving forward. So I I have a similar table listing the jbossas dependencies in JPackage and Fedora. I found that many more packages were up to date in JPackage and that many packages don't even exist in Fedora. The simple fact is that there are very few people packaging for JPackage, and even less packging for Java for Fedora. There is also a very anti-Java attitude from most Fedora users. Packages are even harder to maintain when people try to fracture such a small community in this way. I am not sure what the exact problem is that you're uncovering. We can take the junit4 as an example: (a) junit4 in JPackage is newer than Fedora (before I updated it) and (b) junit4 in JPackage has a full version of hamcrest while Fedora didn't have any version (before I updated it and hacked it up). The hamcrest package was created primarily by non-Red Hat employess/non-Fedora contributors. Also, concerning your webpage: There is no findbugs-specific version of bcel---they simply need a version which has a certain fix in CVS. I didn't make any assumptions here---I verified this with the findbugs devs upstream. The maintainer of cryptix-asn1 probably had a good reason for the snapshot. It's very common in the Java world to use all sorts of unreleased versions of software upstream, and that bad practice is sometimes trickles down unavoidably. The jcip-annotations and jsr-305 versions are taken from maven, so since this is what upstream refers to them by, then I assume them to be correct. -- Sincerely, David Walluck From lfarkas at lfarkas.org Tue Oct 28 11:27:47 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 28 Oct 2008 12:27:47 +0100 Subject: [fedora-java] gstreamer-java not compile on fedora ppc In-Reply-To: <4905BF9D.2020005@redhat.com> References: <4905AD76.8050909@lfarkas.org> <20081027124546.GE3934@redhat.com> <4905BF9D.2020005@redhat.com> Message-ID: <4906F733.7000504@lfarkas.org> Andrew Haley wrote: > Gary Benson wrote: >> Farkas Levente wrote: >>> on fedora gstreamer-java not build on linux-ppc. the relevant build >>> log is here, where you can see that the unit test fails on ppc: >>> http://koji.fedoraproject.org/koji/getfile?taskID=905786&name=build.log >>> http://koji.fedoraproject.org/koji/getfile?taskID=905792&name=build.log >>> is there any tip what can be the reason? >>> is it a gstreamer-java, jna or openjdk bug? >> This looks like this: >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=190 > > Ah, JSR 166 is something I'm very familiar with. thanks, here is the bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=468831 -- Levente "Si vis pacem para bellum!"