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 46791 - Classpath ignored if defined for source root created after root is first used
Summary: Classpath ignored if defined for source root created after root is first used
Status: RESOLVED DUPLICATE of bug 113953
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
Keywords: API
Depends on: 51151
Blocks: 42682
  Show dependency tree
Reported: 2004-07-30 13:44 UTC by Milan Kubec
Modified: 2007-10-24 16:23 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Milan Kubec 2004-07-30 13:44:54 UTC
[custom 20040729, JDK 1.5.0 b60]

Steps to reproduce:
1) Create freeform project, but skip setting
classpath for source folders
2) Open some java file from the project and try to
invoke Code Completion for class that was supposed
to be on classpath

Code Completion pop-up is empty - OK.

3) Open project properties and create valid
classpath for each src folder

Try to invoke code completion again and the CC
pop-up is still empty. Moreover compilation errors
are not dismissed until user does some edits.
After restart CC works OK.
Comment 1 _ ttran 2004-08-02 08:01:26 UTC
Tomas or Jesse?
Comment 2 Tomas Zezula 2004-08-02 09:34:06 UTC
It may be caused by MergerClassPath implementation in the javacore,
which does not listen on the SFBQ.Result. But I would take a look if
the  event is fired.
Comment 3 Jesse Glick 2004-08-02 13:21:05 UTC
You may want to reassign to me. However I did recently fix firing of
changes from the classpath provider in freeform projects, incl. a unit
test which should still be passing, and I think I manually confirmed
with some example (not necessarily the same as Milan's). And anyway I
tried to reproduce this bug just now and could not; worked fine for me.
Comment 4 Tomas Zezula 2004-08-02 13:57:15 UTC
It is a bug in the org.netbeans.modules.ant.freeform.Classpaths.
The change method is not called since the mutablePathImpls is empty.
The mutablePathImpls is empty because the createPath() is not called
from opened(), the aux.getConfigurationFragment("java-data",
FreeformProjectType.NS_JAVA, true) returns null.
The configurationXmlChanged () should do nearly the same as the opened
(). ????? Not sure.
Comment 5 Jesse Glick 2004-08-02 14:05:37 UTC
I need better details to reproduce. As I mentioned before, I was
unable to reproduce this bug when I tried.
Comment 6 Jesse Glick 2004-08-02 14:05:59 UTC
Request details from either Milan or Tomas.
Comment 7 Tomas Zezula 2004-08-02 14:42:58 UTC
I did the following.
Firstly put BreakPoint into changed() method and created new Freeform
project with no source folder at all.
Then I've opened the customizer and added the src folder into it. The
changed () method was not called.
Comment 8 Jesse Glick 2004-08-02 16:51:20 UTC
I will try it with no source folders. Milan's steps said make the
source folders but do not set their classpath, which is what I tried
Comment 9 Jesse Glick 2004-08-02 20:48:54 UTC
Here is what I think the problem is: in Milan's step #2,
ClassPath.getClassPath returns a non-null result... from the default
provider, because the freeform project does not have any ClassPath for
the source tree yet. After that point, it does not matter what the
freeform project does: the Java parsing engine will hold on to that
same ClassPath and not be paying attention to the freeform project at all.

I don't see any solution to this problem using the current APIs. There
is no way for the project to signal to the CP holder that it now has a
classpath for that source file whereas it did not before. The
ClassPathProvider API would have to be enriched to have some kind of
ClassPathResult object which can fire changes, and CP.gCP would have
to merge all CPR's together into one proxy and listen to them all.
Consider something of that sort for E, I guess.
Comment 10 psuk 2004-08-03 07:47:27 UTC
Comment 11 Tomas Zezula 2004-08-03 07:59:32 UTC
I do not understand what Milan means with "but skip setting
classpath for source folders". If he did not set the source folders at
all, as I did, the problem is in caching the ClassPath. But if he set
the source root and did not attach any libraries to it, the
DefaultClassPath provider should not be used and it should work.
Comment 12 Milan Kubec 2004-10-25 10:36:55 UTC
The problem I initially reported seems to be gone.
Comment 13 David Konecny 2004-11-03 14:49:07 UTC
I believe this issue is still valid. Imagine this testcase:

Freeform project has two source roots (src1 and src2) in one
compilation unit. A client retrieves classpath for a file from src2,
attaches listener to the classpath, etc. User reconfigures freeform to
have two compilation units, one per each source folder. There is no
way for client to learn about this, they still listen on classpath
they already retrieved, but the file is part of different compilation
unit and has different classpath now.

Jesse's idea of ClasspathProvider.findClassPath returning a
ClasspathResult which is wrapped in Classpath could solve this.
Comment 14 Tomas Zezula 2007-10-24 15:57:20 UTC
When the issue #113953 will be fixed, the new API is not needed. The freeform project should return for each classpath
root independent classpath which is valid during the whole IDE run.

*** This issue has been marked as a duplicate of 113953 ***
Comment 15 Jesse Glick 2007-10-24 16:07:46 UTC
As I wrote in issue #113953, I doubt that it is possible to fix the case dkonecny describes (and I think mkubec was
initially reporting, though it was unclear) with current APIs. So long as one ClassPath is returned for a set of
codependent source roots, there is no way for the project to later signal that there should be multiple ClassPath's. The
project must be garbage collected, or the IDE restarted.
Comment 16 Tomas Zezula 2007-10-24 16:23:06 UTC
I agree that in case the single classpath instance is returned for set of roots, it's not solvable using current APIs.
But if each source root has its own instance of classpath it should work fine. When the "Single Compilation Unit" is
enabled all these classpaths return the same data, when disabled the classpath roots may differ.