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.
Even when we do ad-hoc project support, it is still annoying that almost nothing works in the text editor for a Java source without an associated project, except syntax coloring etc. We could surely support some limited functionality in this case, by guessing at the right query values. Suggest: 1. Boot classpath should be set to default Java platform, i.e. IDE's own J2SDK, since this is often going to be what is wanted anyway. 2. Source path could be set for a *.java file in case it contains a package declaration which matches its file path. I.e. if you come across /home/me/whatever/org/foo/Foo.java containing the line "package org.foo;" then guess that the source path should be "/home/me/whatever". This would let e.g. Alt-G work within the same source root at least. (Scanning a Java source for a package declaration is pretty cheap, since it has to be the first significant token in the file; you just need a very simple filter/lexer that throws out line and block comments and looks for a package statement. Open File used to have this; it was not very complicated.) 3. COMPILE classpath (also RUN) could be set to be GlobalPathRegistry's merged COMPILE classpath, maybe? Or GPR.getSourceRoots (or similar, minus BOOT paths) might work - code completion would see a source root in the classpath and not have to map it using SFBQ, so it would hopefully use the source root as is. Don't suggest providing any actions (e.g. Compile File), only queries needed for editing capabilities.
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.)