To be able to debug a Java problem, I need class files compiled with -g and the source files. Java packages set up for AOT compilation with GCJ do have debuginfo packages, but they are symbol files for the GCJ-compiled .so files only, with no source files. Has anybody looked at what it would take to set things up for a reasonable Java debugging environment? The source file problem can be solved pretty easily, I think, but what about compiling with -g? I see 4 answers to that question:
1. Never compile with -g. People who want to debug have to recompile their own JARs. 2. Always compile with -g and make everybody eat the bloat. 3. Compile all Java code twice, once to create a debug JAR and once to create the normal distribution JAR. The debug JAR goes into the corresponding debuginfo package. 4. Always compile with -g. Store the original JAR in the corresponding debuginfo package, then strip out the debug symbols and put the resulting JAR into the regular package.
I looked through both the JPackage and the Fedora Java guidelines but did not see anything that addresses this issue. Has anybody thought about this before? I prefer the answer to be "not #1". :-)
This came up, by the way, because I'm having problems with a web service call. It looks like an AXIS bug to me, but I can't step into the AXIS code....
Le lundi 28 avril 2008 à 13:32 -0600, Jerry James a écrit :
I looked through both the JPackage and the Fedora Java guidelines but did not see anything that addresses this issue.
This was never discussed jpp-side. If you have bright spec pattern ideas, just write a jpp or Fedora proposal and I'm sure you won't have any problem in getting it adopted.
"JJ" == Jerry James loganjerry@gmail.com writes:
JJ> Java packages set up for AOT compilation with GCJ do have JJ> debuginfo packages, but they are symbol files for the GCJ-compiled JJ> .so files only, with no source files.
I believe that's actually a bug, which I thought had been fixed. Check the thread rooted at http://www.redhat.com/archives/fedora-devel-list/2007-November/msg01948.html
- J<
Jerry James wrote:
To be able to debug a Java problem, I need class files compiled with -g and the source files. Java packages set up for AOT compilation with GCJ do have debuginfo packages, but they are symbol files for the GCJ-compiled .so files only, with no source files. Has anybody looked at what it would take to set things up for a reasonable Java debugging environment? The source file problem can be solved pretty easily, I think, but what about compiling with -g? I see 4 answers to that question:
- Never compile with -g. People who want to debug have to recompile
their own JARs. 2. Always compile with -g and make everybody eat the bloat. 3. Compile all Java code twice, once to create a debug JAR and once to create the normal distribution JAR. The debug JAR goes into the corresponding debuginfo package. 4. Always compile with -g. Store the original JAR in the corresponding debuginfo package, then strip out the debug symbols and put the resulting JAR into the regular package.
Most of this should not be necessary. We have, or had, a modified version of ecj that always generates debuginfo when an RPM is being compiled, so if there exists any RPM that is missing debuginfo, that is a regression.
Also, when AOT-compiling, we should be generating the full paths for all the source files and therefore all the sources should be in the debuginfo packages.
Please tell me which package is missing these, and I'll find out which of these mechanisms has broken.
Andrew.
Kevin Kofler wrote:
Andrew Haley <aph <at> redhat.com> writes:
Please tell me which package is missing these, and I'll find out which of these mechanisms has broken.
As a wild guess, packages built with IcedTea/OpenJDK maybe?
Well, I'm not going to guess; let's see. :-)
Andrew.
On Tue, Apr 29, 2008 at 2:38 AM, Andrew Haley aph@redhat.com wrote:
Most of this should not be necessary. We have, or had, a modified version of ecj that always generates debuginfo when an RPM is being compiled, so if there exists any RPM that is missing debuginfo, that is a regression.
Also, when AOT-compiling, we should be generating the full paths for all the source files and therefore all the sources should be in the debuginfo packages.
Please tell me which package is missing these, and I'll find out which of these mechanisms has broken.
axis-debuginfo-1.2.1-2jpp.7.fc7.x86_64.rpm which, despite the name, is the current package for F8. It looks like it was generated before the fix went in. Dare I suggest a rebuild of all Java packages of sufficient age?
Also, if anyone cares, my problem did indeed turn out to be a bug in axis 1.2.1 which was fixed in 1.3 or 1.4. (I went straight to 1.4 to check, so I don't know which version fixed the bug.) I see there is a request for an upgrade to 1.4 [1], but it is being held up by some problems with xml-security [2]. I'm not sure we should even bother, though, since the project has been obsoleted by axis2 [3].
References: [1] https://bugzilla.redhat.com/show_bug.cgi?id=231153 [2] https://bugzilla.redhat.com/show_bug.cgi?id=231305 [3] http://ws.apache.org/axis2/
Jerry James wrote:
On Tue, Apr 29, 2008 at 2:38 AM, Andrew Haley aph@redhat.com wrote:
Most of this should not be necessary. We have, or had, a modified version of ecj that always generates debuginfo when an RPM is being compiled, so if there exists any RPM that is missing debuginfo, that is a regression.
Also, when AOT-compiling, we should be generating the full paths for all the source files and therefore all the sources should be in the debuginfo packages.
Please tell me which package is missing these, and I'll find out which of these mechanisms has broken.
axis-debuginfo-1.2.1-2jpp.7.fc7.x86_64.rpm which, despite the name, is the current package for F8. It looks like it was generated before the fix went in.
Right, that makes sense.
Dare I suggest a rebuild of all Java packages of sufficient age?
You can suggest it, but I doubt that it's worthwhile. After all, it's easy for anyone to rebuild the package. Trouble is, they have know way to know that's all they have to do; I know of no easy solution for that.
Andrew.
On Tue, Apr 29, 2008 at 11:20 AM, Andrew Haley aph@redhat.com wrote:
Jerry James wrote:
Dare I suggest a rebuild of all Java packages of sufficient age?
You can suggest it, but I doubt that it's worthwhile. After all, it's easy for anyone to rebuild the package. Trouble is, they have know way to know that's all they have to do; I know of no easy solution for that.
That last sentence is precisely why it is worthwhile. I could have saved a lot of time had I known that.
Jerry James wrote:
On Tue, Apr 29, 2008 at 11:20 AM, Andrew Haley aph@redhat.com wrote:
Jerry James wrote:
Dare I suggest a rebuild of all Java packages of sufficient age?
You can suggest it, but I doubt that it's worthwhile. After all, it's easy for anyone to rebuild the package. Trouble is, they have know way to know that's all they have to do; I know of no easy solution for that.
That last sentence is precisely why it is worthwhile. I could have saved a lot of time had I known that.
I take your point. Does simply rebuilding that RPM fix this problem?
Andrew.
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363: clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
Andrew.
Andrew Haley wrote:
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
Les Mikesell wrote:
Andrew Haley wrote:
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac]
/home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
They'll work; they're binary compatible, not source compatible.
ecj/gcj should still be able to build them, since that's 1.5.
Andrew.
Andrew Haley wrote:
Les Mikesell wrote:
Andrew Haley wrote:
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac]
/home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
They'll work; they're binary compatible, not source compatible.
ecj/gcj should still be able to build them, since that's 1.5.
What about jsp pages and similar things that are recompiled dynamically?
Andrew Haley wrote:
Les Mikesell wrote:
Andrew Haley wrote:
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac]
/home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
They'll work; they're binary compatible, not source compatible.
Hmm, I think I'm wrong about that: we'll get an assert failure.
I think this should be fixed.
Andrew.
On Wed, 2008-04-30 at 10:55 -0500, Les Mikesell wrote:
Andrew Haley wrote:
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
Since OpenJDK is >= 1.6 (ignoring gcj and other GNU Classpath-based JVMs), I'm not sure if there's a better solution. Is there?
Andrew
Andrew Overholt wrote:
On Wed, 2008-04-30 at 10:55 -0500, Les Mikesell wrote:
Andrew Haley wrote:
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
Since OpenJDK is >= 1.6 (ignoring gcj and other GNU Classpath-based JVMs), I'm not sure if there's a better solution. Is there?
Not really, no. We'll have to fix such bugs where they arise.
Andrew.
Andrew Overholt wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
Since OpenJDK is >= 1.6 (ignoring gcj and other GNU Classpath-based JVMs), I'm not sure if there's a better solution. Is there?
The obvious solution is to ship a jpackage nosrc style rpm for the Sun Java versions that you are unwilling to include. That would fix up the fedora rpm dependencies and alternatives symlink weirdness that make using your own downloaded binary painful otherwise. Or maybe someone can get the jpackage people to document which of their packages will work for recent fedora versions.
On Wed, 2008-04-30 at 12:02 -0500, Les Mikesell wrote:
Andrew Overholt wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
Since OpenJDK is >= 1.6 (ignoring gcj and other GNU Classpath-based JVMs), I'm not sure if there's a better solution. Is there?
The obvious solution is to ship a jpackage nosrc style rpm for the Sun Java versions that you are unwilling to include.
This would go against Fedora's goals.
Or maybe someone can get the jpackage people to document which of their packages will work for recent fedora versions.
Maybe you could be that someone :)
Andrew
On Wed, 2008-04-30 at 12:27 -0500, Les Mikesell wrote:
Andrew Overholt wrote:
The obvious solution is to ship a jpackage nosrc style rpm for the Sun Java versions that you are unwilling to include.
This would go against Fedora's goals.
Your goal is to be unusable with java-compliant code?
We insist on all packages being patched to compile with the GCC we are shipping, which has similar, if not worse, pain-in-the-ass breakage issues, especially with C++. Why should Java be any different? Fix the code, ask for help if you need it.
Callum Lerwick wrote:
The obvious solution is to ship a jpackage nosrc style rpm for the Sun Java versions that you are unwilling to include.
This would go against Fedora's goals.
Your goal is to be unusable with java-compliant code?
We insist on all packages being patched to compile with the GCC we are shipping, which has similar, if not worse, pain-in-the-ass breakage issues, especially with C++.
What does that have to do with being able to run other people's standard-compliant code? Or with shipping a nosrc rpm that just deals with fedora's internal strangeness.
Why should Java be any different?
Java is different because people need to download their own copy of a standard-compliant JVM. That's not a problem by itself. The problem is that the fedora rpms have built in dependencies not satisfied by any standard-compliant JVM that you can download, and the fedora file structure expects an odd morass of symlinks that nothing else is going to provide. Jpackage.org used to fill this need, but the relationship seems badly broken these days.
Fix the code, ask for help if you need it.
It's not my code and it doesn't need to be fixed. I want to run things like opennms, alfresco, openfire, spark, opengrok, etc. Some of these may work with 1.6 already but at least opennms doesn't and I don't like surprises.
Les Mikesell wrote:
Andrew Overholt wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac]
/home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
Since OpenJDK is >= 1.6 (ignoring gcj and other GNU Classpath-based JVMs), I'm not sure if there's a better solution. Is there?
The obvious solution is to ship a jpackage nosrc style rpm for the Sun Java versions that you are unwilling to include. That would fix up the fedora rpm dependencies and alternatives symlink weirdness that make using your own downloaded binary painful otherwise.
That seems a little extreme. All we have to do is fix a few incompatibilities.
Andrew.
Les Mikesell wrote:
Andrew Overholt wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac]
/home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
Oh, great. :-(
That's an incompatible change from Java 1.5 to 1.6.
Java 1.6 has a final method clearCache(), 1.5 doesn't:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily going to work for everyone who needs to run current java applications?
Since OpenJDK is >= 1.6 (ignoring gcj and other GNU Classpath-based JVMs), I'm not sure if there's a better solution. Is there?
The obvious solution is to ship a jpackage nosrc style rpm for the Sun Java versions that you are unwilling to include. That would fix up the fedora rpm dependencies and alternatives symlink weirdness that make using your own downloaded binary painful otherwise. Or maybe someone can get the jpackage people to document which of their packages will work for recent fedora versions.
The java-1.5.0-sun package from JPackage doesn't install on Fedora 7 onwards due it having pathname-based dependencies on things that have moved in the great modular X shake-up.
Here's how I get Sun Java 5 installed: http://www.city-fan.org/tips/SunJava5OnFedora
Paul.
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
Rebuilding that RPM fails:
[javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot override clearCache() in java.util.ResourceBundle; overridden method is static final [javac] public static void clearCache() [javac] ^
I've looked, and I don't think it's possible to fix this for Java 1.6.
In http://ws.apache.org/axis/java/apiDocs/org/apache/axis/i18n/ProjectResourceB..., clearCache() is part of the public API. However, org.apache.axis.i18n.ProjectResourceBundle inherits from java.util.ResourceBundle, and that class marks clearCache() as final. We could delete clearCache() and just use the inherited method as a workaround, but it doesn't do the same thing.
The only way to recompile this, or indeed to use it, is with Java < 1.6.
Andrew.
On Thu, May 1, 2008 at 9:21 AM, Andrew Haley aph@redhat.com wrote:
I've looked, and I don't think it's possible to fix this for Java 1.6.
In http://ws.apache.org/axis/java/apiDocs/org/apache/axis/i18n/ProjectResourceB..., clearCache() is part of the public API. However, org.apache.axis.i18n.ProjectResourceBundle inherits from java.util.ResourceBundle, and that class marks clearCache() as final. We could delete clearCache() and just use the inherited method as a workaround, but it doesn't do the same thing.
The only way to recompile this, or indeed to use it, is with Java < 1.6.
Yes. On the other hand, it's an old version of an obsolete product, with at least one serious bug that I can easily demonstrate, so I don't think we should suffer any heartburn over it. What we need to do is work on getting axis2 packaged. Jpackage already has it, which should makes things easier.
Who else out there is interested in getting a modern web services platform put together for Fedora? We should coordinate efforts. I am being forced to consume an external web service that has references to the apachesoap namespace, meaning it can only be consumed by axis. My organization uses CXF to produce our own web services. I can *probably* get my boss to give me some work cycles towards getting one or both platforms packaged for Fedora, and then we can just ditch the obsolete, buggy, unrecompilable axis package.
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
For the benefit of the community at large, I'll repeat some information I just posted to bug #434827. It seems that java-1.5.0-gcj-devel has not been updated on F8 since the release of F8, so the current version is 1.5.0.0-17.fc8, dated 17 Oct 2007. When did the debuginfo fix go in?
Jerry James wrote:
On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley aph@redhat.com wrote:
I take your point. Does simply rebuilding that RPM fix this problem?
For the benefit of the community at large, I'll repeat some information I just posted to bug #434827. It seems that java-1.5.0-gcj-devel has not been updated on F8 since the release of F8, so the current version is 1.5.0.0-17.fc8, dated 17 Oct 2007. When did the debuginfo fix go in?
I asked the java-1.5.0-gcj-devel maintainer, and got the reply:
"We generally don't do updates in Fedora except for security fixes. We fix bugs in Rawhide and if users of the latest stable Fedora badly want the bug fix they can install the Rawhide packages."
It's pretty hard in this case, as that'll pull in java-1.5.0-gcj* as well. Sorry.
Andrew.
On Thu, May 1, 2008 at 9:21 AM, Andrew Haley aph@redhat.com wrote:
I asked the java-1.5.0-gcj-devel maintainer, and got the reply:
"We generally don't do updates in Fedora except for security fixes. We fix bugs in Rawhide and if users of the latest stable Fedora badly want the bug fix they can install the Rawhide packages."
It's pretty hard in this case, as that'll pull in java-1.5.0-gcj* as well. Sorry.
Correct me if I'm wrong in reaching these conclusions: 1. No F8 Java debuginfo package includes sources. 2. This will not be fixed.
Jerry James wrote:
On Thu, May 1, 2008 at 9:21 AM, Andrew Haley aph@redhat.com wrote:
I asked the java-1.5.0-gcj-devel maintainer, and got the reply:
"We generally don't do updates in Fedora except for security fixes. We fix bugs in Rawhide and if users of the latest stable Fedora badly want the bug fix they can install the Rawhide packages."
It's pretty hard in this case, as that'll pull in java-1.5.0-gcj* as well. Sorry.
Correct me if I'm wrong in reaching these conclusions:
- No F8 Java debuginfo package includes sources.
- This will not be fixed.
That seems likely, unless the packages are rebuilt for some reason other than missing debuginfo. We're certainly looking at backporting the fix to java-1.5.0-gcj-devel itself, though.
Andrew.