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.
I am testing the JDK projectizations. To reproduce: 1. Obtain a *current* JDK workspace. (openjdk.dev.java.net won't work, I think; you need a snapshot from inside Sun, maybe from jdkre.sfbay? Dave would know better.) Cd into it. 2. hg clone http://rocoto.sfbay.sun.com:8000/ netbeans 3. Create ~/.openjdk/build.properties and define e.g.: bootstrap.jdk=/space/jdk7 4. Start an NB dev build (I am using 070315 version of java/source) on a fresh user dir. You can use whatever JDK to run NB, it should not matter, although if you skip #3 then you must run NB from JDK 7. 5. Open the netbeans/util project. Just a few packages will display. The IDE is supposed to scan the bootstrap JDK's rt.jar followed by just the included packages. Instead, it seems to scan the IDE's JDK (JDK 6 in my case) followed by everything from src/share/classes. I am guessing this based on the error messages I see on console (general problem filed separately) which refer to several classes which should be excluded: SEVERE [org.netbeans.modules.java.source.usages.RepositoryUpdater]: Coupling error: class file file:/tmp/testud01/var/cache/index/0.1/s12/classes/java/util/LinkedList.sig, source file file:/space/src/j2se-with-nbproject/src/share/classes/java/util/LinkedList.java SEVERE [org.netbeans.modules.java.source.usages.RepositoryUpdater]: Coupling error: class file file:/tmp/testud01/var/cache/index/0.1/s12/classes/java/util/concurrent/FutureTask.sig, source file file:/space/src/j2se-with-nbproject/src/share/classes/java/util/concurrent/FutureTask.java SEVERE [org.netbeans.modules.java.source.usages.RepositoryUpdater]: Coupling error: class file file:/tmp/testud01/var/cache/index/0.1/s12/classes/com/sun/jmx/mbeanserver/PerInterface.sig, source file file:/space/src/j2se-with-nbproject/src/share/classes/com/sun/jmx/mbeanserver/PerInterface.java SEVERE [org.netbeans.modules.java.source.usages.RepositoryUpdater]: Coupling error: class file file:/tmp/testud01/var/cache/index/0.1/s12/classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.sig, source file file:/space/src/j2se-with-nbproject/src/share/classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java SEVERE [org.netbeans.modules.java.source.usages.RepositoryUpdater]: Coupling error: class file file:/tmp/testud01/var/cache/index/0.1/s12/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.sig, source file file:/space/src/j2se-with-nbproject/src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java Furthermore, Go to Type displays all classes twice, whether or not they are included in this project: once for JDK 7 rt.jar, once for src/share/classes. So clearly it has scanned the full tree. Note that these projects do *not* put the output dir on the CP. They set bootcp to the bootstrap JAR, specify no compile CP (~ empty), and specify includes and excludes for src/share/classes. So I would not expect the whole tree to be scanned. BTW trying to do basic code completion tasks results in OOMEs. So it seems things are pretty much broken at the moment.
Probably P2. We really need to have this working for NB 6.0. Please contact me if you need any help setting up the environment.
Hi Jesse, what is the step #3. Who uses ~/.openjdk/build.properties? Does it affect a SourceForBinaryQuery for JDK?
~/.openjdk/build.properties#bootstrap.jdk determines the boot CP for the project. Should not affect SFBQ, unless of course something in metadata is broken, of course. I'm still going to be looking at query results to make sure they are correct, since I heard that someone encountered OOMEs after trying on a novel Windows platform type, due to the lack of a common/architectures/*.properties definition for that platform, which was corrected after the right def was added. (The list should now be complete as it was taken from HotSpot sources.) The trick there is that in order to match the behavior of the makefiles, the output dir has to be set differently according to the host OS.
I don't understand how the JDK sources got into GlobalPathRegistry when you opened the netbeans/util project and no SFBQ returned them.
Sorry, I didn't understand the last comment. src/share/classes is of course the source root for the project. Were you referring to some other JDK sources?
"src/share/classes is of course the source root for the project". Which project? Only the netbeans/util was opened.
src/share/classes is the main source root for all of the netbeans/* projects.
SFBQ was not working due to the way the source folders were registered (FOQ failed on the source root). With that corrected, scanning is correct. There are a lot more problems but I will file them separately.
To be more specific: the initial project metadata I had was "correct" in the sense that it specified includes and excludes for GENERIC source roots as well as JAVA source roots. Thus, SourcesHelper did what it was supposed to - only files which were really included were marked as owned by the project by FileOwnerQuery. However it seems that Retouche ignores FOQ on individual files and only asks FOQ about ownership of the root folder. Since this was not owned by anyone, everything was broken. The "correction" is actually to break the project metadata so that the GENERIC external source roots specify no excludes, and thus any loaded subproject can claim the root folder. I am uncomfortable with this workaround but I can't see what else to do.
x
Changing resolution according to analysis in last comment: a bug in IDE's interpretation of queries, but probably one we do not want to deal with.