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.
In 'Java projects with existing sources', when the specified source folder is located externally respect to the project folder, NB editor seems not to 'live parse' correctly classes on that folder. If you have for example two classes, lets say A and B in the same package with A referencing B, when NB editor try to parse A class, it cannot find B class. This cause problems like 'No suggestions' messages in code completion and incorrect error annotations. I've instead no problems compiling the same project (ant can see the correct class-path).
Created attachment 61311 [details] Three example projects 2 not working
From the example, it is obvious where the problem is. I do not know how to solve it though. This is what happens: -the project has an external source root -the project uses "includes" to include only one package (with subpackages) in the project (not whole source root) -the project (SourcesHelper in particular) does not register the project as an owner of the whole source root, but only of the included folder. -the net effect is that ClassPath.getClassPath(<source root>, CP.SOURCE) returns null (no project owns the source roots), which in turn causes that the caches for the external source root are not created, leading into the described problems. Any idea on how to solve this problem? Thanks.
Possibilities: #1. Whatever code in Retouche calls CP.gCP(sourceRoot, SOURCE) should be fixed to ask CP.gCP(actualSourceFile, SOURCE) in case there is no defined CP for sourceRoot. #2. J2SEProject could define a global CPProvider which would provide information on external source roots of open projects.
Option #1 would require to create FileObjects for the source files, which would have big impact on the performance of the initial scan. Options #2 seems like an workaround, and would IMO result into (more or less) same behavior as making SourcesHelper register the project as the owner of the whole source root. So maybe we should change the SourcesHelper to make the project the owner of the source root?
Option #1 only requires creation of one FileObject, for the first .java file which is actually considered in that root. Regarding option #2, I don't much like the idea of changing SourcesHelper to work around a limitation in the Java parser. SH intentionally registers only that portion of a source root which the project actually declares it "owns". The generic infrastructure correctly handles general includes and excludes of portions of trees; it is the Java infrastructure which places limitations on how projects may be configured.
#1 is really no solution. It requires to create FileObject and call CP.getClassPath=>FileOwnerQuery for every java file. The first java file may be the an excluded file which returns no source path, or it can be a file from project which returns some source path but other file may be from different project having different source path.
Re #1: as Tomas said - one FO is generally not enough, it is necessary to create FOs for Java files (or folders) until a reasonable ClassPath is returned. This may possibly lead into thousands of created FOs and thousands of queries invocations, which would hurt performance of the initial scan. BTW: the BinaryForSourceQuery will also be broken by this - it specifically requires source root as an argument, and if the project is not the owner of its source root, no one will answer.
If it is desirable to register Java projects as the owners of the complete Java source root, even though most of the root is not part of the project, I would suggest creating an overload public void SourcesHelper.registerExternalRoots(int algorithm, boolean minimalSubfolders) throws IllegalArgumentException, IllegalStateException; with minimalSubfolders controlling the clause "If an explicit include list is configured for a principal source root, only those subfolders which are included (or folders directly containing included files) will be registered." where the existing method would delegate to this with mS=true and j2seproject and similar would call it with ms=false.
*** Issue 147121 has been marked as a duplicate of this issue. ***
http://hg.netbeans.org/main/rev/2cae83b86e89