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.

Bug 134919 - Code completion not working for external sources projects
Summary: Code completion not working for external sources projects
Alias: None
Product: java
Classification: Unclassified
Component: Editor (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Zezula
: 147121 (view as bug list)
Depends on: 148185
  Show dependency tree
Reported: 2008-05-13 08:47 UTC by melisg
Modified: 2008-09-30 14:52 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Three example projects 2 not working (386.25 KB, application/x-compressed)
2008-05-13 08:52 UTC, melisg

Note You need to log in before you can comment on or make changes to this bug.
Description melisg 2008-05-13 08:47:47 UTC
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
Comment 1 melisg 2008-05-13 08:52:51 UTC
Created attachment 61311 [details]
Three example projects 2 not working
Comment 2 Jan Lahoda 2008-05-13 15:21:06 UTC
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

Any idea on how to solve this problem? Thanks.
Comment 3 Jesse Glick 2008-05-13 17:00:41 UTC

#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.
Comment 4 Jan Lahoda 2008-05-13 18:44:32 UTC
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?
Comment 5 Jesse Glick 2008-05-13 22:05:37 UTC
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.
Comment 6 Tomas Zezula 2008-05-14 07:26:04 UTC
#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. 
Comment 7 Jan Lahoda 2008-05-18 17:15:45 UTC
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.
Comment 8 Jesse Glick 2008-05-19 21:28:04 UTC
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.
Comment 9 Jan Lahoda 2008-09-15 17:39:22 UTC
*** Issue 147121 has been marked as a duplicate of this issue. ***
Comment 10 Tomas Zezula 2008-09-30 14:52:17 UTC