Gary -
I was trying to build something recently that required org.apache.avalon.framework.logger.Log4JLogger from avalon-framework.
The avalon-framework.jar file in FC4 appears to be missing this class. I grabbed the SRPM file from rawhide and attempted to build that instead. The build failed with this...
[javadoc] java.lang.ClassNotFoundException: com.sun.tools.doclets.standard.Standard not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I've seen this before. It seems that our com-sun-javadoc or com-sun-tools-doclets-Taglet jar should be on the default classpath somehow.
In any case, I noticed that this build of the jar file includes the proper class, but as far as I can tell, this is the same SRPM that was used in FC4. Why wouldn't the FC4 jar file contain the Log4JLogger class?
Thanks!
AG
Anthony Green wrote:
I was trying to build something recently that required org.apache.avalon.framework.logger.Log4JLogger from avalon-framework.
The avalon-framework.jar file in FC4 appears to be missing this class. I grabbed the SRPM file from rawhide and attempted to build that instead. The build failed with this...
[javadoc] java.lang.ClassNotFoundException: com.sun.tools.doclets.standard.Standard not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I've seen this before.
Me too. The binary rpm in FC4 and FC5 was built before we had javadoc, so the error wasn't noticed then.
It seems that our com-sun-javadoc or com-sun-tools-doclets-Taglet jar should be on the default classpath somehow.
It's odd that most things work without, though.
In any case, I noticed that this build of the jar file includes the proper class, but as far as I can tell, this is the same SRPM that was used in FC4. Why wouldn't the FC4 jar file contain the Log4JLogger class?
Some packages check for the existence of certain classes and disable bits of themselves if they're not found. It's possible that avalon-framework has such checks, but is missing some build dependency that forces the necessary class to be installed at build time.
Do you have any idea how to fix the javadoc thing? If so, I can rebuild avalon-framework and see if the class you need appears.
Cheers, Gary
On Tue, 2005-08-09 at 16:03 +0100, Gary Benson wrote:
Some packages check for the existence of certain classes and disable bits of themselves if they're not found. It's possible that avalon-framework has such checks, but is missing some build dependency that forces the necessary class to be installed at build time.
Ah, interesting. Could be.
Do you have any idea how to fix the javadoc thing? If so, I can rebuild avalon-framework and see if the class you need appears.
fitzsim should be able to give us some guidance. My first guess would be to integrate the javadoc classes into java-gcj-compat's tools.jar.
What do you think Tom?
AG
On Tue, 2005-08-09 at 09:30 -0700, Anthony Green wrote:
On Tue, 2005-08-09 at 16:03 +0100, Gary Benson wrote:
Some packages check for the existence of certain classes and disable bits of themselves if they're not found. It's possible that avalon-framework has such checks, but is missing some build dependency that forces the necessary class to be installed at build time.
Ah, interesting. Could be.
Do you have any idea how to fix the javadoc thing? If so, I can rebuild avalon-framework and see if the class you need appears.
fitzsim should be able to give us some guidance. My first guess would be to integrate the javadoc classes into java-gcj-compat's tools.jar.
What do you think Tom?
Yes, I agree these classes belong in tools.jar. I think just doing that will fix the javadoc problem -- you're building with ant, right? I don't think Sun actually includes tools.jar on the system classpath; rather, ant just loads it directly.
Tom
On Tue, 2005-08-09 at 17:19 -0400, Thomas Fitzsimmons wrote:
Do you have any idea how to fix the javadoc thing? If so, I can rebuild avalon-framework and see if the class you need appears.
fitzsim should be able to give us some guidance. My first guess would be to integrate the javadoc classes into java-gcj-compat's tools.jar.
What do you think Tom?
Yes, I agree these classes belong in tools.jar. I think just doing that will fix the javadoc problem -- you're building with ant, right? I don't think Sun actually includes tools.jar on the system classpath; rather, ant just loads it directly.
I ran across this old problem again with a different package.
The following patch to java-gcj-compat solves the problem. Ok to commit?
AG
Index: Makefile.am =================================================================== RCS file: /cvs/rhug/java-gcj-compat/Makefile.am,v retrieving revision 1.25 diff -u -p -r1.25 Makefile.am --- Makefile.am 4 Jan 2006 22:43:15 -0000 1.25 +++ Makefile.am 6 Jan 2006 15:27:41 -0000 @@ -5,6 +5,9 @@ bin_SCRIPTS = \ jardir = $(SDK_LIB_DIR) jar_DATA = tools.jar
+javadoc_jarfile = /usr/share/java/com-sun-javadoc-0.7.7.jar +taglet_jarfile = /usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar + tools_jar_source_files = \ $(top_builddir)/com/sun/tools/javac/Config.java \ com/sun/tools/javac/Main.java \ @@ -15,14 +18,21 @@ tools_jar_class_files = $(tools_jar_sour $(tools_jar_class_files): %.class: %.java $(JAVAC) -d . -I . $<
+javadoc_class_files = com/sun/tools/doclets/Taglet.class com/sun/javadoc/Doc.class + +$(javadoc_class_files): $(javadoc_jarfile) $(taglet_jarfile) + $(JAR) xf $(javadoc_jarfile) + $(JAR) xf $(taglet_jarfile) + rm -rf META-INF + pr13212.so: pr13212.c $(GCJ_BIN_DIR)/gcc$(gcc_suffix) $(CFLAGS) -fPIC -shared -o $@ $< -lgcj
libjawt.so: echo | $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -shared -O2 -fPIC -o libjawt.so -Wl,-soname,libjawt.so -xc - -lgcjawt
-tools.jar: $(tools_jar_class_files) - $(JAR) cMf $@ $(tools_jar_class_files) +tools.jar: $(tools_jar_class_files) $(javadoc_class_files) + $(JAR) cMf $@ $(tools_jar_class_files) com/sun/javadoc com/sun/tools/doclets
java: java.c $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -DJAVA_HOME=""$(JAVA_HOME_DIR)"" -DARCH=""$(CPU)"" -DGCJ_BIN_DIR=""$(GCJ_BIN_DIR)"" -o $@ $< @@ -73,6 +83,10 @@ uninstall-local: DISTCLEANFILES = \ com/sun/tools/javac/Config.java
+mostlyclean-local: + rm -rf com/sun/tools/doclets + rm -rf com/sun/javadoc + CLEANFILES = \ java \ libjawt.so \
* Anthony Green green@redhat.com [2006-01-06 10:31]:
+javadoc_jarfile = /usr/share/java/com-sun-javadoc-0.7.7.jar +taglet_jarfile = /usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar
Perhaps we should make gjdoc have an unversioned jar so that this isn't dependent upon a particular version.
Andrew
On Fri, 2006-01-06 at 10:47 -0500, Andrew Overholt wrote:
- Anthony Green green@redhat.com [2006-01-06 10:31]:
+javadoc_jarfile = /usr/share/java/com-sun-javadoc-0.7.7.jar +taglet_jarfile = /usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar
Perhaps we should make gjdoc have an unversioned jar so that this isn't dependent upon a particular version.
This is probably a good idea for the short term. Long term I would like to see gjdoc merged into libgcj and these com.sun classes moved to java-gcj-compat.
Tom
Andrew
On Fri, 2006-01-06 at 07:31 -0800, Anthony Green wrote:
On Tue, 2005-08-09 at 17:19 -0400, Thomas Fitzsimmons wrote:
Do you have any idea how to fix the javadoc thing? If so, I can rebuild avalon-framework and see if the class you need appears.
fitzsim should be able to give us some guidance. My first guess would be to integrate the javadoc classes into java-gcj-compat's tools.jar.
What do you think Tom?
Yes, I agree these classes belong in tools.jar. I think just doing that will fix the javadoc problem -- you're building with ant, right? I don't think Sun actually includes tools.jar on the system classpath; rather, ant just loads it directly.
I ran across this old problem again with a different package.
The following patch to java-gcj-compat solves the problem. Ok to commit?
Yes.
Thanks! Tom
AG
Index: Makefile.am
RCS file: /cvs/rhug/java-gcj-compat/Makefile.am,v retrieving revision 1.25 diff -u -p -r1.25 Makefile.am --- Makefile.am 4 Jan 2006 22:43:15 -0000 1.25 +++ Makefile.am 6 Jan 2006 15:27:41 -0000 @@ -5,6 +5,9 @@ bin_SCRIPTS = \ jardir = $(SDK_LIB_DIR) jar_DATA = tools.jar
+javadoc_jarfile = /usr/share/java/com-sun-javadoc-0.7.7.jar +taglet_jarfile = /usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar
tools_jar_source_files = \ $(top_builddir)/com/sun/tools/javac/Config.java \ com/sun/tools/javac/Main.java \ @@ -15,14 +18,21 @@ tools_jar_class_files = $(tools_jar_sour $(tools_jar_class_files): %.class: %.java $(JAVAC) -d . -I . $<
+javadoc_class_files = com/sun/tools/doclets/Taglet.class com/sun/javadoc/Doc.class
+$(javadoc_class_files): $(javadoc_jarfile) $(taglet_jarfile)
- $(JAR) xf $(javadoc_jarfile)
- $(JAR) xf $(taglet_jarfile)
- rm -rf META-INF
pr13212.so: pr13212.c $(GCJ_BIN_DIR)/gcc$(gcc_suffix) $(CFLAGS) -fPIC -shared -o $@ $< -lgcj
libjawt.so: echo | $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -shared -O2 -fPIC -o libjawt.so -Wl,-soname,libjawt.so -xc - -lgcjawt
-tools.jar: $(tools_jar_class_files)
- $(JAR) cMf $@ $(tools_jar_class_files)
+tools.jar: $(tools_jar_class_files) $(javadoc_class_files)
- $(JAR) cMf $@ $(tools_jar_class_files) com/sun/javadoc com/sun/tools/doclets
java: java.c $(GCJ_BIN_DIR)/gcc$(gcc_suffix) -DJAVA_HOME=""$(JAVA_HOME_DIR)"" -DARCH=""$(CPU)"" -DGCJ_BIN_DIR=""$(GCJ_BIN_DIR)"" -o $@ $< @@ -73,6 +83,10 @@ uninstall-local: DISTCLEANFILES = \ com/sun/tools/javac/Config.java
+mostlyclean-local:
- rm -rf com/sun/tools/doclets
- rm -rf com/sun/javadoc
CLEANFILES = \ java \ libjawt.so \
On Tue, 2005-08-09 at 07:39 -0700, Anthony Green wrote:
The avalon-framework.jar file in FC4 appears to be missing this class. I grabbed the SRPM file from rawhide and attempted to build that instead. The build failed with this...
[javadoc] java.lang.ClassNotFoundException: com.sun.tools.doclets.standard.Standard not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Actually - it seems the problem is (also?) that gjdoc doesn't provide com.sun.tools.doclets.standard.Standard.
Needs more investigation...
AG
java-devel@lists.fedoraproject.org
-
Andrew Overholt -
Anthony Green -
Gary Benson -
Thomas Fitzsimmons