I think that on project level, with all the work that Serge Beauchamp has done, the Eclipse resource model is already flexible enough to accommodate
anything you could do in other IDE’s. The concepts are
Resource Filters (hide stuff under project root by default)
Project-relative linked resources (pull in stuff outside my project)
Virtual folders (group items).
It just isn’t leveraged today because by default, an Eclipse projects still pull in the stuff under its root and linked resources are not widely
The concept that’s currently missing is what you call “Solutions”. At Eclipse,
A Team Project Set is what you describe from a CM point of view, but
I cannot double click a team project set to open it.
And once imported, it isn’t visible any more as an item to operate on (“update all”, “close”, “switch”).
Working Sets nicely group projects inside a workspace, but
I cannot import/export team-share them easily
Newly added projects are not added to the working set automatically
A workspace is what you describe (group of projects to manage together), but
I cannot team-shared it easily,
I cannot double click to open it;
It isn’t a single item to run global operations easily (eg “update all”)
It is both project list + Preferences, but those two concepts should really be separate.
There is not good concept for “installation-level preferences” versus “workspace-level preferences”.
If I’m not mistaken, some of the Eclipse distros (eg Yoxos, Pulse) are addressing the 2nd problem by making it possible to materialize
a workspace out of CM, and manage preferences and project list separately. Still these concepts are not quite as easy to use as they should be.
Personally, I think that your “solution” would best map to an Eclipse “Workspace” (eg only one solution is open at any one time). Remaining work
Installation-level Preferences / User-level Preferences instead of (or in addition to) workspace-level Preferences.
John Arthorne once said that the association of the osgi.instance.are with the Resources IWorkspace is actually not too tight and it might be possible to tear those two apart, thus solving part of the problem. This problem is also related to supporting multiple
workspaces inside one Eclipse instance.
We need an easier way to open / export / import / team-share / materialize a workspace.
A while ago I filed this bug for that:
FYI, there is still a whole lot of great links and ideas collected here from our previous discussions:
I believe some of those ideas are actually implemented by now (variables in linked resources, virtual folders) whereas other ideas are still very
Martin Oberhuber, SMTS / Product Architect – Development
Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
As an early part of e4, we talked about flexible resources as a thing. In particular, coming from other IDEs, it's pretty frustrating
that Eclipse doesn't have the concept of "Solution"s, to steal the Visual Studio term, or projects that have a mapping from physical file to virtual folder layout you'd see in the project navigator.
Now, this comes up since I just ran into it. One of our developers just added a new plug-in and when I did a git pull, I ended up
with lots of errors because I forgot to import that plug-in. Luckily I had a head up to know it was coming and I've seen this happen so many times, I know where to go look.
In another activity, I'm also looking at how we'd import projects from other IDEs into Eclipse, something that the CDT community
has desired for quite some time. And that's made harder because the projects in those IDEs look a lot different than Eclipse because of this virtual mapping.
Question: is this a need you've seen as well. Should we reopen the flexible resources so we can do this right, assuming the capabilities
aren't there (which I have a feeling some of this was done but not publicized well).