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 201112180600) Java: 1.7.0_02; Java HotSpot(TM) Client VM 22.0-b10 System: Linux version 2.6.38-13-generic running on i386; UTF-8; en_US (nb) steps to reproduce: run "ant" in nb repository to build all clusters. -> open performance module and its two submodules: j2ee, j2se in netbeans(run with clean userdir). After some scanning there are many red badges. If you run the same scenario but build the three projects first, there will be no error badges.
Before the performance module is built, this is missing on the j2se project compile classpath: .../nbbuild/netbeans/extra/modules/org-netbeans-modules-performance.jar which is there when the performance module is built. There is therefore no way for the parser to find the classes from the performance module.
Not a general problem, just applies to these pseudo-modules which are not really supported by the build harness generally.
The issue is that performance is a netbeans.org-type module, but performance/j2se is a standalone module - and standalone modules cannot depend on anything in their platform that is not built yet. Temporary workaround is to force a recalculation of metadata by e.g. editing performance/j2se/nbproject/project.xml (add space and delete) and saving. Cleaner would be one of these options: 1. Make performance.j2se a top-level dir in the main repo, named according to the usual convention (so org.netbeans.modules.performance.j2se), and make it nb.org-type module rather than standalone (so delete <standalone/>, make build.xml import projectized.xml, delete build-impl.xml & platform.properties). Then it can depend on other nb.org-type modules, whether built or not. 2. Make performance and its submodules be part of an external suite, which could not be directly in main or contrib but could be in (e.g.) contrib/other or misc. Then they can have whatever interdependencies make sense. They could employ nb.org modules as test deps but not depend on the tests of those modules (i.e. <test/> in <test-dependency>). 3. Dissolve these modules and move them into functional test dirs of relevant nb.org modules, e.g. java.kit.
This is a known flaw. When creating performance/xyz modules, we intentionally made them a standalone modules (I don't remeber why - #3 would be an option, I guess). They depend on performance module (which is not part of any standard config). If you build performance module before starting the IDE, errors will be gone. The apisupport.project could be a bit more clever and watch for changes in JARs inside of the platform, however.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/26c861b0abe3 User: Jesse Glick <jglick@netbeans.org> Log: Improving diagnosis of #206540 (missing test dep).
(In reply to comment #4) > apisupport.project could [...] watch for changes in JARs inside of the platform Might work - e.g. listening for changes in */update_tracking. Not sure if this is a common enough use case to merit the added complexity.
Rather you should listen for config/Modules changes. Btw. It would help us with our integration with JDeveloper as well.
Report a separate issue if you want. It would still be better to rework the performance pseudomodules so dependencies are understood correctly even without doing a build.