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.
Summary: | IDE doesn't complain about anything, but file won't compile | ||
---|---|---|---|
Product: | apisupport | Reporter: | Petr Dvorak <joshis> |
Component: | Harness | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED WORKSFORME | ||
Severity: | blocker | CC: | jlahoda |
Priority: | P4 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Sample file, file "org.netbeans.test.editor.suites.keybindings.KeyMapTest.java" in Editor module |
Description
Petr Dvorak
2008-12-02 15:36:23 UTC
Created attachment 74429 [details]
Sample file, file "org.netbeans.test.editor.suites.keybindings.KeyMapTest.java" in Editor module
Inconsistency between classpaths used by editor and "Run File". The ProjectSupport class is in the j2seproject's unit tests (which, IMO, is a bug itself). The classpath contains the jar file with the tests (nbbuild/build/testdist/unit/java2/org-netbeans-modules-java-j2seproject/tests.jar). As the SourceForBinaryQuery provides an answer for this jar, the sources (j2seproject/test/unit/src) are used, and the ProjectSupport class is found. At compile time, the tests.jar file is not created, and so the compilation fails. So, either the project type (apisupport.project) should compile tests including necessary dependencies, or the user should be aware of this and compile the j2seproject's tests manually. It is intentional that ProjectSupport is in j2seproject. Leftover from XTest madness. Better not to use it at all if you can avoid it. Just exposes a method from java.source. Anyway, to your problem - the harness will in fact compile tests of modules you have test dependencies on. Do you have a test dep on j2seproject? (Check project.xml.) For efficiency, this step is sometimes skipped in incremental builds if it seems that test deps have already been compiled; I can't remember the exact criteria offhand. Adding functional test dependency to (non-API) module "Java SE Project" solved the issue. If the inconsistency between
what IDE sees and what compiler sees is very specific and influences only NetBeans testers, this issue can be closed as
invalid.
> Better not to use it at all if you can avoid it.
Use of ProjectSupport::waitScanFinished() is the easiest way to determine that the project has been scanned and that
testing itself can start... this is important for test stability.
ProjectSupport.waitScanFinished just delegates to a deprecated method of the same name in SourceUtils in java.source. Tests should probably be using RepositoryUpdater.getDefault().waitScanFinished() instead; this is not deprecated, it just needs a non-exported package (which tests but not regular module code can see). To reiterate, the only reason this method is in j2seproject to begin with is because XTest dumped a bunch of test methods into one class and exposed it to all functional tests by default. Since we cannot break apart a class, it had to go somewhere. open/closeProject are already deprecated in favor of a utility in projectui; createProject has to be in the j2seproject module. If jlahoda agrees, I would mark PS.wSF deprecated and ask that test authors use RU.gD().wSF(). Anyway, this is all tangential to the filed bug, which is some kind of problem in the harness' calculation of which upstream modules need to have their tests built in advance. > Tests should probably be using RepositoryUpdater.getDefault().waitScanFinished() instead;
Thanks for the tip, works nicely...
Please give me steps to reproduce the problem in NetBeans 7.2. |