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.
During a clean build of NB, you see many warnings such as editor.indent.project.compile: warning: [path] bad path element ".../nbbuild/netbeans/platform/modules/org-netbeans-modules-options-api.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/platform/modules/org-netbeans-core.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/platform/lib/boot.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/platform/core/core.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/platform/modules/org-netbeans-modules-keyring.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/platform/modules/org-netbeans-libs-jna.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/platform/modules/org-netbeans-swing-plaf.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/platform/modules/org-openide-io.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/platform/modules/org-netbeans-spi-quicksearch.jar": no such file or directory warning: [path] bad path element ".../nbbuild/netbeans/ide/modules/org-netbeans-modules-projectuiapi.jar": no such file or directory Clearly these files _do_ exist; for example, this module could not compile if org-netbeans-modules-projectuiapi.jar did not exist. Judging by the contents, the warnings are probably coming from the -processorpath option. CacheFSInfo in javac may be to blame, in which case need to file a javac bug, once there is a minimal test case to reproduce.
(In reply to comment #0) > Clearly these files _do_ exist; for example, this module could not compile if > org-netbeans-modules-projectuiapi.jar did not exist. In some cases, the files really do not yet exist. For example, when applemenu is built, openide.io has not yet been built, yet that is in its processorpath due to the runtime-only dep on core.windows (-> o.n.core -> openide.io). This is a bug in the NB harness; either the module list should be sorted taking non-build-prerequisite dependencies into account (defeats the purpose of the element!), or processorpath should be constructed from transitive compile-time dependencies only (rather than using module.run.classpath). This is clearly not the issue when compilation of a module in the enterprise cluster is complaining about the nonexistence of nbbuild/netbeans/platform/modules/org-netbeans-modules-keyring.jar.
See also bug #147393 and bug #157320. After fixing most of the genuine issues (leaving aside some special cases like junit.jar), the rest seem to disappear. This would imply that some CacheFSInfo is being created for compilation of an "early" module, caching a correct negative existence check on some JAR, and then getting reused much later, after the JAR has been created. I don't know why a CacheFSInfo would be used across <javac> invocations; Main.compile seems to create a new Context and a new CacheFSInfo each time.
core-main #79a9bc88746a
(In reply to comment #2) > I don't know why a CacheFSInfo would be used across <javac> invocations In JDK 7 it is not; just a JDK 6 javac bug.
Integrated into 'main-golden', will be available in build *201103170400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/79a9bc88746a User: Jesse Glick <jglick@netbeans.org> Log: #181418: Bogus "bad path element" warnings during multimodule build Define ${module.processor.classpath} as transitive compile-time dependencies, which should all exist during a clean build. Use this for -processorpath, and also for Javadoc's classpath.