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

[Robert Fraser]

Nick Sabalausky wrote:
> "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.

I think Eclipse has a lot of the same things, but gives special names to 
the enclosing folder. For example, in Visual Studio you have a workspace 
file, while in Eclipse, you have a .metadata folder in the workspace. 
The .metadata folder can be thought of as the "workspace file" since any 
folder that encloses this is a workspace. Similarly, in the project root 
directory, there's a ".project" and ".classpath" file. These files can 
be thought of as the "project files", and whatever folder they are in 
Eclipse will treat as the project.

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

The user settings in Eclipse are associated with the workspace and not 
the user (I guess this is what you're complaining about).

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