Community
Participate
Working Groups
As a workaround of bug 245412 (about Resource API not supporting nested projects), it would be nice to create some resource filters that would allow to visualize nested projects in the Navigator. This could be made optional and off by default, similarly to working sets. This view may have some pitfalls (for example with the team providers or compare tree as noticed in bug 245412) but it would be a convenient and good enough implementation for most use-cases.
Wirk in progress here: https://github.com/mickaelistria/eclipse.platform.ui/tree/427768 . Feedback and help are obviously welcome.
Hi Mickael, just need an explanation: what are you actually trying to do which is not already available? I mean, resource filters already exist and one can create them for nested projects. The Gradle integration plugin for SpringSource Tool Suite (STS) is currently using and handling them exactly this way, when you import a Gradle multiproject using the hierarchical layout. Do you mean something like an automatic resource filter creation when nested projects are found? And if so, when (at import time, at creation time...?)?
(In reply to Mauro Molinari from comment #2) > Do you mean something like an automatic resource filter creation when nested > projects are found? And if so, when (at import time, at creation time...?)? The idea is to have a single CNF content provider + resource filter that would allow in the navigator tree, instead of a folder, to show the project tree. See the current GitHub branch for some basic stuff. It's aimed to be a generic provider/filter which could work for an Eclipse project (relying on availability of a .project file). Similar to how working set are implemented, and that I'd like to be as easy to enable/disable. For the future: As resources are expected to appear only once in navigator, other references to the project could be replaced by placeholders (basically a folder with a decorator) to highlight the fact that the content of the project is loaded in workspace but shown in another location. User could right-click on it and select "Show project <blah> here". Then the placeholder would become where the project is shown.
Actually, we can just show projects at multiple location (no need for placeholder or similar concept): working sets already allow that and it doesn't seem to cause any issue.
Suggested change: https://git.eclipse.org/r/21892 . It works only in Project Explorer. It's all about an action in the contextul menu. If you don't use it, everything is as it has always been. If you use it, it shows project in another context. The data is not persisted for now, so you have to re-show as project everytime your start Eclipse. So far, I don't think it's necessary to persist it. It could be another iteration or even another feature request.
(In reply to Mickael Istria from comment #5) > Suggested change: https://git.eclipse.org/r/21892 . It works only in Project > Explorer. Hi Mickael, So what's the usecase here? You have one open project that contains multiple nested projects (currently as folders). Then you activate a mode? And what does it look like before and after? PW
Created attachment 239980 [details] Screenshot > So what's the usecase here? The use-case is to be able to view a project under another project that contains it as an addition to the "flat" project organisation of the workspace. It's for example useful when importing a big directory as a project (let's say for example a Git repo such as eclipse.platform.ui), and then be able to show the actual PDE projects under the eclipse.platform.ui project. It would also make sense in the context of Maven projects: assuming the root project is already available, and that modules do contain a .project, it would allow them to be shown under the parent project. In general, I see this as an alternative to usage of working sets in some cases. > You have one open project that contains > multiple nested projects (currently as folders). Then you activate a mode? You simply select the folder that actually contains a .project and select "Show as project" in context menu. Then the project is shown instead of the folder > And what does it look like before and after? Cf screenshot.
(In reply to Mickael Istria from comment #7) > > You simply select the folder that actually contains a .project and select > "Show as project" in context menu. Then the project is shown instead of the > folder How is this different from the Open As Project we already committed? Does it do the same thing except not bring the project to the root? PW
The actions by themselves are indeed similar. However, the main piece of this contribution is addition of content provider and filters to Resource Tree that allows to show a project inside another project. As for actions, I'm open to any suggestion to make them work better with the new "Open as project".
A style like the one of Visual Studio ( http://www.rapidqualitysystems.com/Content/Screenshots/New/VisualStudio.png ) is actually closer from the Eclipse new logo, and looks good. I can imagine a dark blue background, and some orange/yellow based lines or backgrounds for tabs.
(In reply to Mickael Istria from comment #10) > A style like the one of Visual Studio ( > http://www.rapidqualitysystems.com/Content/Screenshots/New/VisualStudio.png > ) is actually closer from the Eclipse new logo, and looks good. > I can imagine a dark blue background, and some orange/yellow based lines or > backgrounds for tabs. As you probably understood, this comment was meant to another bug. Sorry for the noise. Back to nested project, those interested can try the newer patch set, which fixes a couple of issues detected thanks to various feedback got during EclipseCon. It's surprisingly working quite well with EGit, so that change in nested project are shown also mark the parent project as containing changes.
Note that current suggested PR doesn't store the "nesting" state, so projects are display in "flat" way after each restart. Any way, it would be good if someone could give it a try and provide feedback in term of usability. Does it have any chance to make for Luna? Or will it for 4.5 (ideally a very early milestone) ?
(In reply to Mickael Istria from comment #12) > Note that current suggested PR doesn't store the "nesting" state, so > projects are display in "flat" way after each restart. > Any way, it would be good if someone could give it a try and provide > feedback in term of usability. > Does it have any chance to make for Luna? Or will it for 4.5 (ideally a very > early milestone) ? Sorry for the late response. After a quick look only, I think this *might* cause more confusion than remedy, because "normal" tools will probably not be able to see and deal with the new structure that the user sees in the UI. We can continue the discussion once Luna has shipped, since it's definitely too late to add this to Luna. Setting target to 4.5 to decide whether we want this feature and if so, include it in Mars.
(In reply to Dani Megert from comment #13) > Sorry for the late response. No problem. > After a quick look only, I think this *might* > cause more confusion than remedy, because "normal" tools will probably not > be able to see and deal with the new structure that the user sees in the UI. Do you have examples of such tools that have issues? Or maybe some workflows that can cause confusion? Note that this is an opt-out, just like working sets, so people are not forced to use it, and if not project is nested, everything behaves exactly as it currently behaves. But overall, since this doesn't affect the Resource API and since it relies on the CNF implementation, it seems to integrate well with most IDEs parts. I'm now using it regularly and I didn't notice anything that becomes less usable because of that. I have the feeling that SCM markers can be a weak point. I use EGit, which works like a charm and even cascade change markers to the parent project. I don't know (and I admit I don't care much at the moment) for other ones.
(In reply to Mickael Istria from comment #14) > (In reply to Dani Megert from comment #13) > > Sorry for the late response. > > No problem. > > > After a quick look only, I think this *might* > > cause more confusion than remedy, because "normal" tools will probably not > > be able to see and deal with the new structure that the user sees in the UI. > > Do you have examples of such tools that have issues? > Or maybe some workflows that can cause confusion? I was e.g. thinking of a new Eclipse developer who uses the resources API to iterate over the workspace and then never gets the structure he sees in the 'Project Explorer'.
(In reply to Dani Megert from comment #15) > I was e.g. thinking of a new Eclipse developer who uses the resources API to > iterate over the workspace and then never gets the structure he sees in the > 'Project Explorer'. Well, that's indeed a potential point of confusion for plugin developers but: * I guess these developers will quickly understand that Resource API is not exactly what's visible when they'll try "folder.getProject(name)" and see that this method doesn't exist, and when they'll notice that only the WorkspaceRoot can return projects. * In the patch, I stated "SHOW project here", not "PLACE project here" to remove some of the confusion * We shouldn't really focus on plugin developers, they are already advanced Eclipse users, so that's the kind of thing they'll figure out. My focus is more on Eclipse IDE users.
For those interested, I made the code available for build, local installation & contributions at GitHub. Cf https://github.com/mickaelistria/jbosstools-eclipse
Note that the suggested implementation "only" adds a view filters and content providers. They could be disabled by default, and that users could still enable via the "Customize View..." menu. Would this opt-in approach make you consider this change as good to go for Mars?
Newer Gerrit change: https://git.eclipse.org/r/#/c/38119/ With this new change, whether to show nested projects or not is controlled from the Project Explorer view menu, similarly to enablement of Working Sets or Package Presentation.
Adjusted summery to match the latest approach.
(In reply to Mickael Istria from comment #19) > Newer Gerrit change: https://git.eclipse.org/r/#/c/38119/ > > With this new change, whether to show nested projects or not is controlled > from the Project Explorer view menu, similarly to enablement of Working Sets > or Package Presentation. I like this new approach. See my comments in the Gerrit change.
(In reply to Dani Megert from comment #21) > (In reply to Mickael Istria from comment #19) > > Newer Gerrit change: https://git.eclipse.org/r/#/c/38119/ > > > > With this new change, whether to show nested projects or not is controlled > > from the Project Explorer view menu, similarly to enablement of Working Sets > > or Package Presentation. > > I like this new approach. See my comments in the Gerrit change. Submitted with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=fc3e247569b74ef9cedf48cf46bd8b27f79b61ba
Suggested New and Noteworthy entry: https://git.eclipse.org/r/#/c/40253/
(In reply to Mickael Istria from comment #23) > Suggested New and Noteworthy entry: https://git.eclipse.org/r/#/c/40253/ And manual test plan added to https://wiki.eclipse.org/Platform_UI/Component_Area_Testing#Nested_projects
(In reply to Mickael Istria from comment #23) > Suggested New and Noteworthy entry: https://git.eclipse.org/r/#/c/40253/ Submitted with https://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=1f1623794312534a1130c944422ed9473ba7d7fd
Mickael, can you test in or test candidate and set the bug to VERIFIED if this works in the build?
(In reply to Lars Vogel from comment #26) > Mickael, can you test in or test candidate and set the bug to VERIFIED if > this works in the build? I tried it with yesterday I-Build. Is it OK or should I try again on a new build? Also, I'm not convinced I'm the better one to test this, since developers often make bad testers for their own stuff ;)
I tried this today with the Mars RC (4.5.0.20150603-1639). I could not figure out why it was not working. It turns out, that I was trying this in Package Explorer, and it only seems to work in Project Explorer. Is it a bug that it does not work in Package Explorer? I imported ~130 maven modules all from one large source tree, using m2e, if that has anything to do with it.
(In reply to Scott Carey from comment #28) > I tried this today with the Mars RC (4.5.0.20150603-1639). > I could not figure out why it was not working. It turns out, that I was > trying this in Package Explorer, and it only seems to work in Project > Explorer. > Is it a bug that it does not work in Package Explorer? The hierarchical view of project wasn't implemented in Package Explorer. Package Explorer doesn't automatically consume extension of common navigator framework, so it requires more work to implement it in Package Explorer. FWIW, I do not plan at all to work on adding features to the Package Explorer (I'd rather actually invest in getting it removed for the sake of consistency, see bug 427897 and family). But you can still open a bug to JDT/UI asking for nested project layout to be included in Package Explorer as well. Can you please add on bug 427897 what are the reasons that make you use Package Explorer instead of Project Explorer ?
For me there is one reason to use Package explorer: https://bugs.eclipse.org/bugs/show_bug.cgi?id=471587 referenced libraries (and you need those if you use source lookup) are all expanded and are such big space waste that they annihilate all the great work you did with nested projects.
