This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version = NetBeans IDE Dev (Build 201103230400) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.6.0_23 Runtime = Java HotSpot(TM) 64-Bit Server VM 19.0-b09 error report --- Loading source file C:\Sun\commons-httpclient-3.1-src\commons-httpclient-3.1\src\java\org\apache\commons\httpclient\util\URIUtil.java... Constructing Javadoc information... Standard Doclet version 1.6.0_23 Building tree for all the packages and classes... C:\Sun\commons-httpclient-3.1-src\commons-httpclient-3.1\src\contrib\org\apache\commons\httpclient\contrib\ssl\AuthSSLProtocolSocketFactory.java:357: warning - @param argument "clientHost" is not a parameter name. C:\Sun\commons-httpclient-3.1-src\commons-httpclient-3.1\src\contrib\org\apache\commons\httpclient\contrib\ssl\AuthSSLProtocolSocketFactory.java:357: warning - @param argument "clientPort" is not a parameter name. C:\Sun\commons-httpclient-3.1-src\commons-httpclient-3.1\src\contrib\org\apache\commons\httpclient\contrib\ssl\EasySSLProtocolSocketFactory.java:170: warning - @param argument "clientHost" is not a parameter name. C:\Sun\commons-httpclient-3.1-src\commons-httpclient-3.1\src\contrib\org\apache\commons\httpclient\contrib\ssl\EasySSLProtocolSocketFactory.java:170: warning - @param argument "clientPort" is not a parameter name. C:\Sun\commons-httpclient-3.1-src\commons-httpclient-3.1\src\contrib\org\apache\commons\httpclient\contrib\ssl\StrictSSLProtocolSocketFactory.java:192: warning - @param argument "clientHost" is not a parameter name. C:\Sun\commons-httpclient-3.1-src\commons-httpclient-3.1\src\contrib\org\apache\commons\httpclient\contrib\ssl\StrictSSLProtocolSocketFactory.java:192: warning - @param argument "clientPort" is not a parameter name. java.lang.NullPointerException at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUse(PackageUseWriter.java:180) at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageList(PackageUseWriter.java:124) at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUse(PackageUseWriter.java:110) at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUseFile(PackageUseWriter.java:99) at com.sun.tools.doclets.formats.html.PackageUseWriter.generate(PackageUseWriter.java:78) at com.sun.tools.doclets.formats.html.ClassUseWriter.generate(ClassUseWriter.java:116) at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:92) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) Generating C:\Sun\commons-httpclient-3.1-src\httpClient\dist\javadoc\org/apache/commons/httpclient/\package-use.html... 6 warnings C:\Sun\commons-httpclient-3.1-src\httpClient\nbproject\build-impl.xml:854: Javadoc returned 1 BUILD FAILED (total time: 16 seconds)
Seems to be a JDK problem.
Long time open bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5101868 As can be seen in the report above we do pass the forbidden mixture of slashes and backslashes: ":\Sun\commons-httpclient-3.1-src\httpClient\dist\javadoc\org/apache/commons/httpclient/\package-use.html" Closing as wontfix is not good enough in this case IMO. We should fix the construction of parameters on our side, if possible. Reassigning to javadoc module.
Generate javadoc is project action. Right?
>We should fix the construction of parameters on our side, if possible. We don't do it. It's Ant business to construct the cmd args from file set. In fact the Ant's Javadoc task passes 2 files to cmd javadoc tool. One containing the options: -charset UTF-8 -d C:\tmp\http\httpcomponents-client-4.1.1\dist\javadoc -docencoding UTF-8 -encoding UTF-8 -splitindex -use -source 1.6 The filesets to be generated are passed in separate (second) file and all files in it have correct separatorChar. Here is an example of one entry: C:\tmp\http\httpcomponents-client-4.1.1\httpclient\src\main\java\org\apache\http\auth\NTCredentials.java I've tried it on the Windows and it seems that the Ant (1.8.2) is passing the names correctly. Closing as works for me.
Product Version: NetBeans IDE Dev (Build 201103230400) Java: 1.6.0_23; Java HotSpot(TM) 64-Bit Server VM 19.0-b09 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb) Userdir: C:\Users\emiddio\.netbeans\dev does not work with this version -- now submitting entire project that fails
Created attachment 107368 [details] zip or my project that will not generate javadoc
Thank you for the project I am able to reproduce it with it. Unfortunately it's JDK bug for which there is no workaround in the IDE. The IDE just calls Ant with fileset of java files for which the javadoc should be created. Even the Ant creates correct command line (see attached command line arguments). The problem is inside javadoc tool. If you don't need package and class usage you can turn it off in the project properties/Documenting/Class and Package Usage pages to workaround the this problem.
Created attachment 107378 [details] Ant's javadoc command line args
Fails also on Ubuntu, so not just a backslash issue. The real problem in this project is that src/examples is being included as a source root, which it should not be; if you need to work this examples, they ought to be in their own project (which you would never bother to run Javadoc on) depending on the primary project. If you remove this source root, Javadoc works fine. (Probably src/contrib should be in its own project, too - otherwise you wind up dumping contrib classes into the same JAR.) If you are committed to keeping src/examples in the same project, perhaps because you have no intention of using its output JAR anyway, a trivial workaround for the javadoc bug is to override -javadoc-build in build.xml and comment out <fileset dir="${src.examples.dir}" excludes="${excludes}" includes="${includes}"> <filename name="**/*.java"/> </fileset> Of course that requires manual customization of the build - and knowledge of the cause of this crash! Better would be for build-impl.xml to automatically avoid documenting any classes in the default package (which are almost certainly not intended to be part of an API to begin with, since no code could import them): [added] vvvvvvv <fileset dir="${src.examples.dir}" excludes="${excludes},*.java" includes="${includes}"> <filename name="**/*.java"/> </fileset> ... [ditto for other declared roots] ... <fileset dir="${build.generated.sources.dir}" erroronmissingdir="false"> <include name="**/*.java"/> <exclude name="*.java"/> <= [added] </fileset>
Fixed jet-main 8039b0ec43cc
Integrated into 'main-golden', will be available in build *201103310400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8039b0ec43cc User: Tomas Zezula <tzezula@netbeans.org> Log: #197129:Javadoc generation fails w/ NPE in PackageUseWriter.generatePackageUse when default package used