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.
[Build jet-main-639-on-090515] The compile classpath for tests seems to be different inside the IDE and in ant. Seems that module dependencies are considered transitive by ant, but not transitive by the IDE. To reproduce: 1. Download the attached module suite, unpack, open in the IDE, including the module. 2. Open FooTest from the org.netbeans.test.module1 test package - the file shows compilation errors inside the editor. 3. Try to build the file (F9) - it succeeds. 4. Try to test the project - compilation of tests passes (test fail because there are no tests). 5. Try to run "ant test-build" in the module directory - the tests are compiled without problems. The example module depends on java.source, which depends on java.lexer. ant build process seems to consider the dependency transitively, the IDE non-transitively, leading into the above problems.
Created attachment 82349 [details] Sample project (note that it is *not* the same project as in issue #165444).
Looks like harness CP is correct, according to harness README, both runtime and compile CP for tests should contain module.run.classpath, I'll fix apisupport. However I wonder if it is really necessary to have such a huge test classpath, why not just direct dependencies?
core-main #69d8113c117b
Integrated into 'main-golden', will be available in build *200905290201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/69d8113c117b User: Richard Michalsky <rmichalsky@netbeans.org> Log: #165446: fixing test CPs according to harness spec
I think it was the harness that was wrong. README said nothing about nonrecursive compile dependencies but intuitively they should *not* pull in the module's transitive run CP; nor should the test compile CP include the module's run CP as in this example. The current setup leads to poor performance as the compile CP of e.g. web.jsf/test/qa-functional/src is enormous. I will see if I can fix the harness and apisupport to match it. (Workaround is probably to move all functional tests into web.kit so they do not bother regular developers.)