Bugzilla – Full Text Bug Listing
| Summary: | Inconsistencies in nested project support | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Walter Brunauer <walter.brunauer> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | dev, eclipse, johann.draschwandtner |
| Version: | 3.2.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
The UI bug described in steps to reproduce is a duplicate of bug 147727 (fixed in 3.3 stream). I believe the remainder of your proposal is a duplicate of discussion in bug 35973. (In reply to comment #1) > The UI bug described in steps to reproduce is a duplicate of bug 147727 (fixed > in 3.3 stream). I believe the remainder of your proposal is a duplicate of > discussion in bug 35973. > Sorry I missed bug 147727. Thanks. However, this proposal IMHO seems to be different to bug 35973, as I am not talking about UI visualization or VC management, but a change in the Eclipse platform resource model only, which would simply lead to IContainer parents potentially managing IProject children at any level. I know this is a fundamental change, but that's all, no property layering, no UI handling, etc. implied. How different services or views would deal with this would not be defined by this change. The IDE I am working on did support project structure management from the beginning. Until now, this meant to visualize project references in the UI and consider it during builds, and to make sure no circular dependencies occur between project references. But now this changed, as nested projects come into play. So all I would like to see is some Eclipse platform resource model functionality allowing me to traverse the resource tree accordingly. And IMO the most logical way would be to allow to traverse from an outer project into a nested project just like for folders, but not providing duplicated resources for the part of the outer project covered by the nested project already. Of course, in the list of all projects, nested projects should be included. And it would only be a property of IProject, if it is nested, and an access method to the outer project. Other than that, nested project handling would need to be considered on all the functionality mentioned above (creation, import, open/close, etc.). Bug 35973 is about more than just presentation of nested projects in the UI. This problem is not as simple as just defining a new notion at the resource level. Any plugin traversing the workspace, from the UI, to builders and other tools, would need to be reconsidered and possibly recoded to support such a change. If you don't like bug 35973 as a duplicate, I could mark it as a duplicate of bug 126283, or any of the other dozen duplicates... it all comes down to the same problem, with different twists on the solution space. See bug 35973 comment 19 for a summary of our most recent exploration of the problem. *** This bug has been marked as a duplicate of bug 35973 *** |
Build ID: M20060921-0945 Steps To Reproduce: 1. Create a project outside (parallel to) a workspace. 2. Create a second project inside the first project. vs. 1. Create a project inside a workspace. 2. Try to create a second project inside the first project. More information: Some background One obviously is able to create nested projects outside a workspace file system branch. Why is this not possible inside a workspace as well? The only thing prohibiting this seems to be some new project wizard functionality checking for this. If an outer/nested project combination is created outside a workspace first, then a workspace is created and opened on top of this combination, and finally the two projects are imported into the new workspace one by one, it seems to work just fine. But that's only part of a bigger problem around nested projects... General proposal Support nested projects in the Eclipse resource API. Any project content provision should end on all found nested project folders, so no folders are available containing .project files from within the outer project. This would then not duplicate logical resources from physical ones, as it does now. Instead such nested project folders, any nested project should be provided with its content, independent from the state of the outer project. It should support: - outer/nested project creation outside and inside of workspaces (of course except .metadata) in no particular order - outer/nested project import with all nested projects in no particular order - outer/nested project unique naming (e.g. internally combining all found project's names or directory names containing .project files from the same file system branch above) - outer/nested project open/close management including all nested projects - outer/nested project moving/renaming/deletion handling This would allow to deal with source code bases, where historically and/or logically, different scopes need to be managed independently, which are physically located in the same file system tree. This often is the case for existing C/C++ systems. Example: Physical file system structure (complete system): + System .project + Apps .project + App1 .project + Modules + Foo .project + Bar .project + App2 .project + Modules + Toto .project + Tata .project + Libs .project + LibA .project + LibB .project + LibC .project + Workspace + .metadata ... Logical project structure available in workspace (only Apps and Libs imported, with App2 And LibC closed, but Toto of App2 opened): + System.Apps [project] .project + System.Apps.App1 [project] .project + Modules [folder] + System.Apps.App1.Foo [project] .project + System.Apps.App1.Bar [project] .project + System.Apps.App2 [closed project] + System.Apps.App2.Toto [project] .project System.Apps.App2.Tata [closed project] + System.Libs [project] .project + System.Libs.LibA [project] .project + System.Libs.LibB [project] .project System.Libs.LibC [closed project]