Red Hat Bugzilla – Bug 157685
classpathref attribute in javadoc target fails
Last modified: 2007-11-30 17:11:06 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Firefox/1.0.2 Fedora/1.0.2-3 Description of problem: In classpathx-mail we have workaround patches for build.xml: --- ../mail-20050512.orig/build.xml 2005-05-12 14:26:00.000000000 -0400 +++ build.xml 2005-05-12 14:29:01.000000000 -0400 @@ -208,8 +211,7 @@ <target name='javadoc' depends='init' description='Build the JavaDoc API documentation'> <mkdir dir='${doc}'/> <javadoc destdir='${doc}' use='true' author='true' - windowtitle='GNU JavaMail API documentation' - classpathref='nntp.classpath'> + windowtitle='GNU JavaMail API documentation'> <doctitle><![CDATA[<h3>GNU JavaMail</h3>]]></doctitle> <bottom><![CDATA[©]]> Copyright 2003, 2004 The Free Software Foundation, All rights reserved</bottom> When I remove these patches, the ant build fails with: BUILD FAILED /home/fitzsim/rpmbuild/BUILD/mail-20050512/inetlib-20050512/build.xml:159: Reference provider.classpath not found. at org.apache.tools.ant.types.Reference.getReferencedObject(org.apache.tools.ant.Project) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.types.Path.dieOnCircularReference(java.util.Stack, org.apache.tools.ant.Project) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.types.Path.dieOnCircularReference(java.util.Stack, org.apache.tools.ant.Project) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.types.Path.list() (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.types.Path.addExisting(org.apache.tools.ant.types.Path, boolean) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.types.Path.addExisting(org.apache.tools.ant.types.Path) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.types.Path.concatSystemClasspath(java.lang.String) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.taskdefs.Javadoc.execute() (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.UnknownElement.execute() (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.Task.perform() (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.Target.execute() (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.Target.performTasks() (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.Project.executeTarget(java.lang.String) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.Project.executeTargets(java.util.Vector) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.Main.runBuild(java.lang.ClassLoader) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.Main.startAnt(java.lang.String[], java.util.Properties, java.lang.ClassLoader) (/usr/lib/libant-1.6.2.jar.so) at org.apache.tools.ant.launch.Launcher.run(java.lang.String[]) (/usr/lib/libant-launcher-1.6.2.jar.so) at org.apache.tools.ant.launch.Launcher.main(java.lang.String[]) (/usr/lib/libant-launcher-1.6.2.jar.so) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) We should fix FC4 ant's support for classpathref. Version-Release number of selected component (if applicable): ant-1.6.2-3jpp_6fc How reproducible: Always Steps to Reproduce: 1. remove the docbuild patches from classpathx-mail.spec 2. build the classpathx-mail rpm Actual Results: doc target fails Expected Results: doc target should succeed Additional info:
Xref: http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=14950
I'm changing the "Component" field from "ant" to "classpathx-mail". This is not a bug in Ant -- it's a bug in Classpathx Mail's and Classpath Inetlib's build.xml files. Ant handles the "classpathref" attribute of the "javadoc" task just fine. The problem is that the versions of GNU Mail and GNU Inetlib that we ship in this RPM both reference the non-existent path id "nntp.classpath". This used to be defined in early versions of these build.xml files, but not any longer. In the case of Inetlib, Chris fixed the bug in CVS over a year ago (on 2004/06/21): http://savannah.gnu.org/cgi-bin/viewcvs/classpath/inetlib/build.xml.diff?r1=1.2&r2=1.3 In the case of GNU Mail, the bug is still there, so I filed a bug report (see comment #1 above). I updated classpath-inetlib-docbuild.patch and classpathx-mail-docbuild.patch to fix the issue in a slightly more correct way: https://www.redhat.com/archives/fedora-cvs-commits/2005-November/msg00720.html ... and rebuilt the RPM as classpathx-mail-1_0-4jpp_3fc. As far as I can tell, the (re-)generated Javadoc hasn't changed as a result of this fix. The only change that I observe by diffing the pre- and post-fix /usr/share/javadoc/javamail-1.3.1/ trees is in files named foo/bar/Baz-uses.html, for instance: /usr/share/javadoc/javamail-1.3.1/javax/mail/Address-uses.html Even there, the diff seems to be due to a reordering of package names on the page. The actual content is the same. This may be due to gjdoc's brokenness: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23917 I'm closing this ticket.