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: | Support basic editing capabilities of projectless Java sources | ||
---|---|---|---|
Product: | java | Reporter: | Jesse Glick <jglick> |
Component: | Unsupported | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dkonecny, mmatula, ttran, tzezula |
Priority: | P2 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 41606 | ||
Bug Blocks: |
Description
Jesse Glick
2004-04-08 19:17:55 UTC
Such basic query impls need to be given a lower priority than anything else since they are only guesses. Might be an important user migration issue. Martin mentioned to me that this could be even more important after the refactoring merge - otherwise you can't even jump to methods in the editor toolbar, etc. I could try to implement a prototype. Martin suggested always returning non-null for ClassPath.getClassPath. I think this is not a good idea: e.g. if the source is *not* in the right package structure, you really should not return some fake source root just for the sake of returning something. Apparently the refactoring infrastructure does not fully handle null CPs (used in a lot of places?), but hopefully this could be fixed in one place in the infrastructure - MergedClassPath or whatever it is - rather than in the general ClassPath API, which may be used directly by any module and should not return meaningless values. Checking in src/META-INF/services/org.netbeans.spi.java.classpath.ClassPathProvider; /cvs/java/j2seplatform/src/META-INF/services/org.netbeans.spi.java.classpath.ClassPathProvider,v <-- org.netbeans.spi.java.classpath.ClassPathProvider new revision: 1.4; previous revision: 1.3 done Processing log script arguments... More commits to come... RCS file: /cvs/java/j2seplatform/src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProvider.java,v done Checking in src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProvider.java; /cvs/java/j2seplatform/src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProvider.java,v <-- DefaultClassPathProvider.java initial revision: 1.1 done Something strange here. CP.COMPILE requests are served by asking GPR for all COMPILE paths registered. This means if you have projects A and B open, A dep on B, and open some projectless Java file, it will get code completion for B but not A. Bug or intentional? At the beginning it was intentional. The COMPILE classpath of unknown source == to GlobalPathRegistry.COMPILE classpath. This does not offer in the code completion classes from projects sources. I will add to the COMPILE path also all sources not covered by the GPR.COMPILE path. Is it possible to take GPR[SOURCE] and include those in your COMPILE path? I am not sure what happens if you list sources in your COMPILE path. (There is no API to get the binaries from sources, only sources from binaries.) |