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.
Steps to reproduce: 1) Select a root of standalone module project 2) Perform Generate Architecture Dscription from popup. Ant shows this error message: init: arch: /usr/local/pzajac/newdev/dev/netbeans/harness/common.xml:337: You must define e.g. javadoc.arch=${basedir}/arch.xml in project.properties BUILD FAILED (total time: 0 seconds)
Of less importance for external modules.
Note: if you follow its instructions, arch.xml will be pregenerated. But there is still a problem for external modules: File ..../arch.xml cannot be parsed: no protocol: ${nbroot}/nbbuild/antsrc/org/netbeans/nbbuild/Arch.dtd I'm not sure how it would be possible to support arch XML files for external modules. Where should Arch.dtd (and more importantly, Arch-api-questions.xml) come from? Can't simply put them in the harness, because arch.xml needs to statically refer to the correct path using XML includes, and ${harness.dir} is computed using Ant properties only. Probably the usage of a XML entity includes for arch generation should be dropped; each arch.xml should refer to a fixed, versioned Arch.dtd on www.netbeans.org/dtds/ and the questions should be included using document() in the stylesheet. Alternately, as a workaround for external modules, arch.xml could use entity includes to load some XML file in the build/ dir, which would be created on demand by the arch target and point to the absolute pathname of the questions file inside the harness. Not sure if it's possible to refer to the DTD this way. Yardo, what do you think?
I know external directories do not work. I had a lot of problems when I tried to write tests for Arch.java recently. I had to introduce property - do not validate... Both Arch.dtd and Arch*.xml can be found using EntityResolver. The real problem is reference to those xhtml definitions in lib/external, but it is not my invention, I do not know much about those. I do not know what is document() on style sheet.
Even if you use an EntityResolver during stylesheet processing time, you still won't get code completion or Validate in the IDE while editing, so that's not ideal. document() is an XSLT function you can use to load an XML file with content while processing. Much better idea than using entity includes to load the questions.
*** Issue 64432 has been marked as a duplicate of this issue. ***
I think I have a fix on my local disk. At least I was able to generate arch for profiler...
I commit as soon as I find out that I can build javadoc.
"#61231: generate arch works in standalone modules" /cvs/nbbuild/antsrc/org/netbeans/nbbuild/Arch-fake-xhtml.dtd,v <-- Arch-fake-xhtml.dtd initial revision: 1.1 done Checking in nbbuild/antsrc/org/netbeans/nbbuild/Arch.dtd; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/Arch.dtd,v <-- Arch.dtd new revision: 1.20; previous revision: 1.19 done Checking in nbbuild/antsrc/org/netbeans/nbbuild/Arch.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/Arch.java,v <-- Arch.java new revision: 1.38; previous revision: 1.37 done Checking in nbbuild/test/unit/src/org/netbeans/nbbuild/ArchQuestionsTest.java; /cvs/nbbuild/test/unit/src/org/netbeans/nbbuild/ArchQuestionsTest.java,v <-- ArchQuestionsTest.java new revision: 1.8; previous revision: 1.7 done RCS file: /cvs/nbbuild/test/unit/src/org/netbeans/nbbuild/arch-profiler.xml,v done Checking in nbbuild/test/unit/src/org/netbeans/nbbuild/arch-profiler.xml; /cvs/nbbuild/test/unit/src/org/netbeans/nbbuild/arch-profiler.xml,v <-- arch-profiler.xml initial revision: 1.1 done Checking in apisupport/harness/nbproject/project.properties; /cvs/apisupport/harness/nbproject/project.properties,v <-- project.properties new revision: 1.10; previous revision: 1.9
I don't think the Arch-fake-xhtml.dtd trick is a good idea. It prevents people from using other XML validation tools and full XHTML. Better to just use <!ENTITY % xhtml PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> unconditionally in Arch.dtd, and when libs/external/dtds/xhtml1-20020801/DTD/xhtml1-strict.dtd is determined to be available at runtime in Arch.java, use it; otherwise the user must have an internet connection, sorry. Also is = new InputSource(new java.net.URL(replace).openStream()); is.setSystemId(replace); is too much work; just new is = new InputSource(replace); And I presume this is a mistake (see "cvstunnel.czech"!): <!DOCTYPE api-answers PUBLIC "-//NetBeans//DTD Arch Answers//EN" "../../../../../../cvstunnel.czech/trunk/nbbuild/antsrc/org/netbeans/nbbuild/Arch.dtd" [ <!ENTITY api-questions SYSTEM "../../../../../../cvstunnel.czech/trunk/nbbuild/antsrc/org/netbeans/nbbuild/Arch-api-questions.xml"> ]>
P3 - > P2 please fix it for Nb50 or remove this action from pupup menu of non nb.org module.
cvs -q ci -m "#61231: Using the real definition of xhtml. 1. the one from libs/external if found, 2. connect to website, 3. if connection fails, fallback to the fake xhtml one" Checking in antsrc/org/netbeans/nbbuild/Arch.dtd; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/Arch.dtd,v <-- Arch.dtd new revision: 1.21; previous revision: 1.20 done Checking in antsrc/org/netbeans/nbbuild/Arch.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/Arch.java,v <-- Arch.java new revision: 1.39; previous revision: 1.38 Re: cvstunnel is there intentionally - it simulates the real arch.xml we had problem with, of course the text can be anything, feel free to change it.
Nope, the new logic in the entity resolver did not work. The code source was always ant.jar or something like this, and in practice the test never triggered, and in fact ant -f apisupport/project/build.xml arch failed saying that <dfn> was not defined. I think I know how to fix, though.
Working so far, still testing...
Now should be fixed. Checking in nbbuild/antsrc/org/netbeans/nbbuild/Arch.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/Arch.java,v <-- Arch.java new revision: 1.40; previous revision: 1.39 done The remaining problems we cannot fix: 1. If you are making an external module, and you are offline (or behind an unconfigured proxy etc.), building the arch desc will be slow since it needs to time out before it figures out that it should use local versions of things. 2. If you are making an external module and you are offline, only a common subset of XHTML will be permitted. To use arbitrary XHTML, go online.
The web browser is opened before the arch.html file is generated. Steps to reproduce: 1) Create standalone module project 2) Perform Generate Architecture description action The webrowser is opened with message missing arch.html file. But the file is present after few seconds in build folder.
Yes, the first time you make the file the web browser is opened when it should not be. But that does not affect anything else; just close the browser, next time it works. If you care about it, please file it separately - probably P4.
I've filled issue #67438