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: | Scan of JDK subproject ignores excludes | ||
---|---|---|---|
Product: | java | Reporter: | Jesse Glick <jglick> |
Component: | Source | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | db1959 |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 98266 |
Description
Jesse Glick
2007-03-16 00:18:36 UTC
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. |