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.
Yes, the description is a solution. Here's the problem: - We have a bunch of things which are project types, or project-like. The thing people always expect they should do is somehow extend Java (or whatever) project - which is usually not what we want them to do. Also, often these things are (or should be) physically distinct from the project they care about - and can benefit from being kept distinct. Examples: - UML - currently you create a UML project that corresponds to your Java project - JNLP - this was originally implemented as it should have been, as a separate project; but the UI folks found it weird that it was a separate project - Analyzer - the native tools team is integrating that. It has a concept of "experiments" - and experiment is a directory, and is very project-like All of these things benefit, engineering-wise, from remaining physically distinct from the projects they model or generate something for. So what I'm proposing is really a way to achieve composition, rather than inheritance, with projects: We already have ProjectAction, and a module can add ad-hoc actions to a project which are visible on appropriate projects and not visible on inappropriate ones. What is missing is the logical corrolary to that: The ability for a module to add ad-hoc nodes to a project. There are three ways this can be implemented: - The simplest: ProjectUI scans the subdirs for projects and shows their nodes as subnodes of itself. I will attach a patch for this. It has the problem that some projects probably shouldn't be exposed. - Less simple: Provide a similar interface to LogicalViewProvider and ProjectFactory specifically for identifying projects under a parent project which should be able to add nodes - Least simple (but probably most performant): Provide some additional ProjectNodeFactory interface, with similar fail-fast test semantics to ProjectFactory.isProject() so all directories don't have to be scanned for projects, but rather some ProjectFactory-like object can do a quicker test. Anyway, doing this will make a lot of things possible, UI-wise, and greatly reduce the need to open up more API in specific projects - and also greatly reduce the need for modules to do things like modify build scripts and so forth. Think of it as a way of avoiding "project natures", possibly permanently, but getting all the benefits of them.
Created attachment 30985 [details] Simplest possible implementation I could conjure to do project composition
Created attachment 30986 [details] Slightly improved patch - eliminated superfluous FilterNodes
Created attachment 30987 [details] Variation which introduces ProjectFactory extension NestedProjectFactory w/ isNestedProject(FileObject), rather than exposing all nested projects
BTW, if I'm not explaining this clearly or you don't understand what I'm trying to achieve, let me know. The basic idea is just to let nested projects underneath a project *look* as if they're part of the main project - by adding actions (you can already do that) and nodes to the logical view of the project. It seems to me a very clean solution to the problem of extending projects and project "natures" - and also a problem "natures" doesn't really solve - which is when you have >1, say, UML model or JDNC config or such for a project.
BTW, the advantage to the approach in the last patch is we can avoid exposing things like all the projects under the Java module. A project can say it is a project, a nested project (shouldn't be openable on its own), or both.
We already have an SPI for extending project nodes under API review. We do not wish to tie it to nested projects specifically, I think; we wish to allow any module to extend any project's logical view for whatever reason. *** This issue has been marked as a duplicate of 72441 ***