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.
Open openide.awt or any other NetBeans module with public API and "Generate Javadoc". Usually the build emits warning with a link to arch.xml document, just like in following example. The link is clickable, but when clicked nothing happens. Deleting: /home/jarda/src/netbeans/fixes/nbbuild/build/tmp/javadoc-colors/org-openide-awt.txt Replacing entity -//W3C//DTD XHTML 1.0 Strict//EN at http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd with file:/home/jarda/src/netbeans/fixes/nbbuild/external/xhtml1-dtds/xhtml1-strict.dtd /home/jarda/src/netbeans/fixes/openide.awt/arch.xml: answers were created for questions version "1.26" but current version of questions is "1.29" /home/jarda/src/netbeans/fixes/openide.awt/arch.xml: some questions have not been answered: [compat-deprecation, resources-preferences] Run with -Darch.generate=true to add missing questions into the end of question file
The problem is somewhere in org.netbeans.modules.xml.XMLDataObject. It correctly declares that there shall be EditorCookie in its lookup, but when asked to create it following method is called: // it is called by super class constructor @Override protected EditorCookie createEditorCookie () { return null; } No surprise the output window does not have EditorCookie to jump to. Btw. possibly write a unit test to ensure EditorCookie can be obtained from XMLDataObject.
Reproducible. See also issue #160208, though it might be unrelated. It _does_ have an EditCookie. Perhaps the Ant module (which creates this hyperlink) could check for EditCookie, OpenCookie, etc., but this ought not be necessary. My best guess as to cause: changeset: 107234:0021c796787c user: Jaroslav Tulach <jtulach@netbeans.org> date: Tue Nov 04 14:28:28 2008 +0100 files: openide.loaders/src/org/openide/loaders/DataObject.java openide.loaders/src/org/openide/loaders/XMLDataObject.java openide.loaders/test/unit/src/org/openide/loaders/XMLDataObjectTest.java description: #151767: Don't require Children.MUTEX when create XMLDataObject's lookup though this does look to be guarded against use in subclasses by if (getClass() == XMLDataObject.class)
Fixed in trunk: http://hg.netbeans.org/main/rev/251cf388a482 See the attached screen shot: - javadoc is generated for the NB module "xml" (XML Support) - a required .xml file (arch-empty.xml) is opened after mouse clicking on an appropriate link (D:\Projects\trunk\main\nbbuild\javadoctools\arch-empty.xml: answers were created for questions version "1.23" but current version of questions is "1.29") in the window "Output"
Created attachment 85010 [details] screenshot
Please include a brief description of the problem and/or fix in the Hg changeset summary. If there is only an IZ number, it becomes very difficult to browse file history meaningfully. Cookie editorCookie = getCookieSet().getCookie(EditCookie.class); return (editorCookie instanceof EditCookie ? (EditorCookie) editorCookie : null); looks very suspicious. If you asked for EditCookie, you will always get an EditCookie (or null), so the typecheck is useless. But the method requires EditorCookie, so the cast can fail with a CCE! Perhaps you meant return getCookieSet().getCookie(EditorCookie.class); ? Or maybe the createEditorCookie override should just be deleted?
Weird fix. Simple return getCookieSet().getCookie(EditorCookie.class) would do the same, would it not? Catching an exception! Why? Also a little unit test would be beneficial for future maintenance.
Thanks for comments. Fix has been modified: http://hg.netbeans.org/main/rev/3b719ba56f00 (superfluous method "createEditorCookie()" has been deleted). A description (a bug description) has been added to Hg changeset summary.
Integrated into 'main-golden', will be available in build *200907230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/251cf388a482 User: Alex Petrov <alexpetrov@netbeans.org> Log: Fix for issue [#167935]