- No more importing, just adding a .project file just provides more functionality.
- Repo working directories could be automatically discovered.
- Project/package presentation is not limited by workspace hierarchy, novel presentations could be explored.
- Global preference problem is solved.
- No refreshing, ever.
So what about different plugins/target definitions? Simple. Start multiple instances of Eclipse, each of which can have it’s own metadata location. I already do this (and I bet others do too) because switching workspaces is so painful; at any time I might have three or four instances of Eclipse running. Doesn’t this create a preference problem again? In my perfect world, Eclipse checks my home directory for existing metadata and asks me if I’d like to import the preferences into the new instance.
Ok, so I know I’m dreaming. But removing a whole layer of complexity that developers have to contend with would make Eclipse much more appealing IMHO.
Working Sets don't allow you to customize the perspective per working set. So if I want to customize it, I have to create a different perspective, and when I switch working sets, I also have to switch perspetives manually.
I disagree that multiple workspaces are a worse practice, in fact I'll argue otherwise.
If I put all of these together (even assuming there were no Target Platform restrictions) it would massively clutter up my Eclipse workspace. And then I'd have to use Working Sets to isolate those each conceptual group of projects, but why bother? There is nearly no benefit, AFAIK, to Working Sets, and yet there are *a lot* of cons. It's more work and a lot of eclipse components don't work with Working Sets at all.
Multiple workspaces makes things a lot simpler when you are working with multiple unrelated projects (I dont mean Eclipse IProjects, just work projects). For example I have four Eclipse workspaces: one for RustDT+Goclipse+DDT+MelnormeEclipse development, another one for Eclipse Platform contributions, another one for CDT contributions, and finally another one for working with Rust and Go projects.
For example the "Build All Projects" command does not work with Working Sets (this has implications for projects that don't use incremental builders). The "Refresh All" command (a command I use a lot due to use some external Git scripts on some projects) doesn't work with WS either. The Git Repositories view doesn't work with Working Sets.
Multiple workspaces allows you to have different Eclipse plugins per workspace. Working Sets does not. This is useful for me when the work projects I work on a given session use completely different plugins than others.
Working Sets are more work for the user to manage. Whenever you add a new project, you have to add it to the corresponding working set. Not all wizards support this. (RustDT/Goclipse/DDT don't, for example). But even with the wizards that do support it, it's still more work than simply using multiple workspaces - you still have to select in the wizard which Working Set to add it to. With multiple workspaces there is no such need, it just adds it to the current workspace.
And in the face of all this, the only downside of multiple workspaces is you have to copy/manage prefs, but that is a one-time cost when setting up a new workspaces (or when you change a preference). The cons of Working Sets on the other hand hit you nearly every time you use them.
And I don't even see any other advantage of Working Sets, other than you can combine and activate multiple working sets at once, you are not restricted to just one. But I was never in a situation where that was useful.
ide-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit