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: | Classpath ignored if defined for source root created after root is first used | ||
|---|---|---|---|
| Product: | java | Reporter: | Milan Kubec <mkubec> |
| Component: | Classpath | Assignee: | Tomas Zezula <tzezula> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | blocker | CC: | dkonecny, jglick, tzezula |
| Priority: | P3 | Keywords: | API |
| Version: | 4.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 51151 | ||
| Bug Blocks: | 42682 | ||
|
Description
Milan Kubec
2004-07-30 13:44:54 UTC
Tomas or Jesse? 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. 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. 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.
I need better details to reproduce. As I mentioned before, I was unable to reproduce this bug when I tried. Request details from either Milan or Tomas. 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. 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 before. 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. subcomp->classpath 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. The problem I initially reported seems to be gone. 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. 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 *** 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. 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. |