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.
As the number of independent NetBeans modules is growing, it became uncomfortable to use <api url="http://www.netbeans.org/" /> for mutual references. The suggestion is to use <api nbapi="Loaders" /> instead.
While you're at it, consider keeping some data about each API in a central place in nbbuild/javadoctools/ so that template.xml doesn't need to hardcode everything. TBD exactly how this should work.
I am not sure I can handle this for 4.0. Of course, if there is a pressing need, I can, but otherwise this may wait a while. The solution I had in mind was to modify javadoctools/template.xml to not hardcode the list of tokens to replace, but generate them. When we would be processing openide/util we would generate mapping from @OPENIDE/UTIL@ to proper URL in some file(s). All other invocations of template.xml would use (include) that file and could then refer to all the mappings generated in advance. The mappings should include references to roots of javadocs (like @OPENIDE/UTIL@) and also to definitions of apis from arch*.xml answers (like @API/GROUP-JAVA/NAME-LoadersAPI@), the arch*xml XSLT would then understand <api ref="..." /> tag that would be replaced by <a href="@API/GROUP-...." />, so regular uses of the arch*xml infra would not need to know the encoding convetion of the @...@ form. Is this the right direction?
General idea sounds right to me.
Let's try this, or at least parts of this for 4.2. I believe I have good enough patch for javadocs to generate its references. I plan to apply it on Friday.
Created attachment 21778 [details] Implementation of general idea (at least ModuleInstall links correctly to SharedClassObject)
If it works, OK... 1. Do you have a script or something to generate the included XML fragments? 2. Shouldn't javadoc.name overrides be removed from all project.properties?
Created attachment 21849 [details] Modifying the javadoctools, to dynamically generate information about already build javadocs (only for modules that are not known currently, those are pregenerated) and canonicalizing names of javadoc dirs to match the dashed code base name of the module
Standardized use @your-module-code-base-name@ in the javadoc or arch questions as described at http://openide.netbeans.org/tutorial/api.html#write