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.
See comments in issue #57733. There is no specific defined meaning for SubprojectProvider; it is merely a device permitting the GUI infrastructure to know when some projects should be opened. If refactoring-related code wishes to know what projects a given project "depends on", it should use the reliable and documented method of examining the classpath(s) used in the project's source root(s), mapping back any binary entries to sources using SFBQ, and looking up any owner projects for those dependent source roots. Both refactoring and j2ee/refactoring modules seem to make this mistake.
SubprojectProvider should rather have specific meaning if it is an API. Refactoring module does refactoring in projects, that are 1. opened and 2. relevant in terms of project dependency. I don't understand why we shouldn't use it. From the doc and class name it does exactly what we want if it works.
SP does have one meaning: it controls how the UI for Open Project and Open Required Projects works. That is all. Quoting from the Javadoc: "Optional ability of projects which may have a list of "subprojects". The exact interpretation of this term is at the discretion of the project, but typically subprojects would be "built" as part of this project or somehow used in it as dependencies; or they may just be contained or agglomerated in it somehow." In other words, there is *no* necessary relationship between SubprojectProvider and classpath dependencies. A project is free to implement SpP however it likes (so long as there are no cycles in the graph), purely for UI reasons. Refactoring functionality, however, needs to know specifically what source roots depend on (the build outputs of) other source roots, which is precisely what ClassPath + SFBQ are for - and note that these APIs do not even require that source roots be associated with projects at all, so long as there is some query provider around. For illustration, consider a freeform project with source roots A, B, and C. A depends on B, but not on C, which is standalone. If I select a source file in C and ask for usages, I do not wish to search in A or B, only C; if I select a source file in B, I wish to search for usages in A and B, but not C. This is all inside one project - project boundaries and subproject relationships do not come into play at all!
I agree wholeheartedly on this. I was shocked to learn that I had to define <subprojects> to get refactoring to work across my downstream projects. It is clear from the declared output and classpaths of the projects involved. [In my cases the projects are decidedly *not* subprojects, but rather are various projects building on top a core/base library.] [Note that in this case as in others it is *not* acceptable to require that the outputs reside within a projects' directory tree for this functionality to work (see bug #57656). For free-form projects in particular there are often many other factors forcing another output location. It is clear that mapping does not actually require this (at least when the projects involved are open in the IDE).]
Re. usage of <subprojects> - it is conventional, but not required, to declare libraries you are depending on as "subprojects" (in the UI: "Required Projects"), to match behavior of fixed project types in the IDE. Re. externally located build outputs: should be OK, so long as - the project producing the build output declares it properly - this project has been opened, so that the IDE is aware of where the folder/JAR came from (These requirements have nothing to do with refactoring as such; affects also other parts of the IDE, e.g. code completion popup Javadoc.)
This issue really should be addressed in a 4.1 auto-update -- not wait until 4.2!
Clearly as per this SPR <subprojects> declarations are required for multi-project refactoring -- but I can see the general utility in this high-level "this project depends on projects x, y, and z" capability. I also note that the <subprojects> behavior does not currently place restrictions on jar output placement. On another front, however, go-to-source (which uses the SFBQ as I understand it) *does* currently place restrictions on the locations of the jar output. See issue 57656. The functionality currently only works if the jar output resides within the project directory. I was thus concerned that refactoring might inherit this bug once it no longer relied on <subprojects> for inter-project relationship information. Oddly it seemed to me that adding <subprojects> declarations fixed this -- but I was clearly mistaken. The only cases where this is working are those I've used the Library Manager as a workaround. Again see issue 57656.
Please keep issue #57656 comments out of this issue except where directly applicable, to reduce confusion.
Checking in Util.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/classpath/Util.java,v <-- Util.java new revision: 1.11; previous revision: 1.10 done