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

[Nick Sabalausky]

"Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
news:g0kv7d$2gvg$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> whatever the heck it uses instead of the nice clean "project file and 
>> workspace file" mechanism of IDE's like Visual Studio and CodeBlocks just 
>> doesn't seem to make any sense at all.
>
> ... Hidden folder in the workspace and 2 project files?

The whole concept of projects and workspaces in Eclipse just strikes me as a 
bit...clumsy.

With Notepad, you start it up, create whatever you need to create, and then 
save it as a single file, named whatever you want, placed wherever you want 
(Or, of course, you can save first just to create the file, and then add 
whatever to the blank file). Simple, easy, flexible, and IMO the way it 
should be.

Visual Studio extends this simple, flexible mechanism to the concept of both 
projects and workspaces (with .NET-era Visual Studio using the term 
"solution" instead of "workspace"). I start up Visual Studio, create 
whatever I want to create (or save first), and then save the project to one 
single file named whatever I want, placed wherever I want. The workspace is 
also saved to one single file named whatever I want, placed wherever I want. 
If I add another project to the workspace, same thing, one nice neat file 
per project and one per workspace. Each file references whatever files it 
needs, and if you move/rename something, you can always update the 
references either in the IDE or in the actual files themselves.

Granted, Visual Studio does automatically generate one extra "user settings" 
file per project (or is it per workspace? whatever, either way...), but I've 
never found that to be a problem. It's just data that wouldn't make sense to 
put under source control anyway, and nothing important enough that 
recreating the data is anything you'd even give a conscious thought to 
anyway (IIRC, frame layout settings, etc).

But with Eclipse: First, you can't even be in the main UI at all without the 
session already being attached to an already named-and-saved workspace 
(Hence, the "choose a workspace" startup dialog.) That's a bit of a clumsy 
and arbitrary restriction and doesn't appear to provide any real benefit 
(imagine if Notepad worked that way).

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).

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.