Eclipse's "Workspaces" (Was: What you use D for?)

[Nick Sabalausky]

"Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
news:g0qhir$v5v$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> Secondly, being from the Java world, Eclipse follows the (misguided, IMO) 
>> Java philosophy of marrying its self with the filesystem. "A workspace 
>> contains projects and projects contain sources, therefore workspaces and 
>> projects should be folders, not files." Yea, well, the problem is that's 
>> forcefully imposing an arbitrary choice.
>>
>> If I want to follow a convention of projects and workspaces being 
>> folders, I can already do that with VS-style projects and workspaces. I 
>> make a folder for the workspace, stick a workspace file named 
>> ".workspace" in there, make subfolders for the projects, stick project 
>> files named ".project" in those, etc. True, in that case, projects and 
>> workspaces aren't *really* folders, they're each a folder *and* a file, 
>> but Eclipse already has to do that anyway.
>>
>> You can *kinda* work around this in Eclipse with "Create Project From 
>> Existing Source", but there are still limitations (a project and 
>> workspace can't occupy the same directory - which breaks my usual style 
>> of sticking the project and workspace files next to each other in the 
>> top-level of a "MyProgram" directory).
>
> If that's the case then you're probably misunderstanding the point of 
> workspaces and making thm too small in scope. For example, I use a single 
> workspace for all my projects (well, two; I always use Descent as an 
> Eclipse runtime).
>
>> Plus, switching workspaces makes the entire Eclipse program reload (slow, 
>> and why, for instance, should the help window close when I load a 
>> different workspace?)
>>
>> Also, Eclipse seems to marry the ideas of "user settings" together with 
>> that of "workspace". For instance, there are some settings, like syntax 
>> coloring settings and "Open Associated Perspective: Remember my 
>> decision", that are associated with a workspace, but should be treated as 
>> global user settings (or at least, global within the scope of a user 
>> account).
>>
>> Now if Eclipse had a notion of "Targets" (like CodeWarrior, IIRC) that 
>> were children of projects, and contained the source files, then that 
>> would solve most of my problems with Eclipse's workspaces, because then I 
>> could treat a "Workspace" as container for user settings, and treat "A 
>> project with target(s)" as alternate terminology for VS.NET's "A solution 
>> with project(s)". But as far as I can tell, Eclipse doesn't seem to have 
>> this.
>
> I think you're tying the "workspace" to the "project" too closely. Visual 
> Studio tends to associate those two concepts. In Eclipse, "workspace" and 
> "user" are tied together, as there rarely seems to be any need to have 
> multiple workspaces per user.

If that's the case then I'd argue Eclipse's concept of a "project" is too 
limited/narrow (Unless it allows nested projects?).

Many times, I'll be working on some development project (that is, a 
"project" in the everyday english sense of the word, not an IDE concept of 
"project") that consists of more than one separate but related targets. Each 
target will have its own set of sources. For example, there might be:

- "My Application"
- A tool/utility or two that are specific to "My Application"
- A library of functionality shared between the main app and the 
app-specific tools/utils
- A sample plugin to test/demonstrate "My Application"'s plugin mechanism

And there may be some other totally unrelated "My Other Application" that 
has similar complexity.

So, that means there are a few requirements (all somewhat interrelated):

------------
1.

There needs to be a three-level hierarchy that, regardless of terminology, 
boils down to:

"Group of targets"->"Target"->"Sources/Assets"

2.

If I'm working on "My Application", I don't want the workspace to distract 
me with all of the targets associated with "My Other Application" as well as 
every other little program I write using the IDE.

3.

The "My Application" and "My Other Application" might be very different. For 
instance (all hypothetical), one might be a GameBoy Advance game I'm writing 
in plain old C, and the other an opensource Win32 email client written in 
Java and Lua on which I merely contribute, and maybe a third 
program/set-of-programs that's some big enterprisey thing for work using 
every damn language imaginable.

3A: While some settings should be associated with me as a user (ex: the 
highlighting settings for a given language, or text-editing keyboard 
shortcuts)...

3B: ...other settings should be specific to either "My Application" or "My 
Other Application" (ex: auto-formatting settings, certain panels 
opened/closed, certain panels resized differently).

Eclipse's "Perspectives" sound like a potential semi-solution to this, but 
from my limited understanding of them, it sounds like they're not 
project-specific, and don't cover all the types of settings I'm talking 
about here.
------------

If Eclipse's Workspace is treated as a system-wide "user" concept, then you 
have a mere two-level hierarchy of "Project"->"Sources". So you're lacking 
the "Group of targets"/"Solution" level that ties together "My Application" 
with its associated utils/libs/etc, while assigning appropriate "Group 
Settings" to that entire group and nothing more than that group. This breaks 
requirements #1 and #3B.

You could try to counteract this by treating "Workspace" as an ad-hoc "Group 
of targets"/"Solution" concept, but then not only do you get the awkwardness 
I mentioned in my previous post, but requirements #2 and #3A are broken.

This could all be solved with, for example, a concept of "nested classes", 
or "a project consists of targets which have sources". But, I'm not aware of 
anything like this in Eclipse.