Eclipse: Should I create a workspace for each project?

I am simply wondering whether it is bes开发者_StackOverflow社区t to put all of my Eclipse projects into one workspace, or do a 1 workspace per 1 project. I am just a solo developer, for hobby more or less, but the apps I create do actually have production versions that are running on rather frequent cron jobs, so its almost like an amateur production environment.

The only problems I have noticed so far is for exporting JARs, I have the potential to include source files from other projects which seems like it could get messy.

I used to keep separate workspaces, but got tired of the difficulty in keeping settings consistent between them. Now what I do is create working sets for different projects and change the current window working set to filter out everything except what I want to work on. So far this has worked fine for me.

Since each project can have multiple working sets, and the window working set can be any combination of working sets, it's quite easy to only see what you want at any given time this way.

I create Eclipse workspaces around products, because for me, a product can have multiple projects within them, for example like having core libraries compiled into one jar in a project, this is used by other projects.

In terms of production environment, you would want products running in different directory structures, much cleaner that way. And in eclipse the workspace creates a directory with workspace name. So, create workspaces based on product/app rather than one or more projects within them.

Not only do I keep separate workspaces for each project but I keep separate copies of Eclipse also. This is because I typically have to put projects on ice for long periods and return to them (with little notice) and they absolutely must build. I can't take the chance that some plugin I've installed for my latest project (maven based) will interfere with the build process of one of the legacy systems (ant based). For the record I do document the eclipse environment for those legacy systems but I don't have time to mess with eclipse when patching a production bug.

If the projects are interrelated (i.e. have dependencies on each other) then it quite often makes sense to have them in the same workspace. Also, if you are working on several projects to solve a related problem, the same applies.

You will waste a lot of time changing workspaces unnecessarily otherwise, especially when the IDE will immediately show you the impact the changes in one project has on another.

I would use separate workspaces for different "groups" of projects. For example you might want to combine your main app project AND the unit testing project together in the same workspace.

Maybe I'm unlucky, but Eclipse often (once a month, say) dies on startup, typically in the "Initializing Java Tooling" stage. The recommended solution seems to be to create a new workspace. If you have all your projects in one workspace, this can be a pain. I think smaller workspaces may mean the crash is less likely to occur.

As the Preferences are workspace-specific, I tend to have a enormous workspace open - I'm too lazy to sync some settings between workspaces (e.g. repositories...).

On the other having too much projects open in a single workspace can slow down Eclipse - so the least I have to do is to close projects I'm not working with. I manage a lot of relative short-term projects (at most one month) in Eclipse, that reside in the same workspace (and in most cases the same repository), so this setup gives me a bigger flexibility.

If you have several, interrelated projects, then keep them in the same workspace. If you can identify group of projects, that are always used together, but the groups are used independently, then put such project sets into different workspaces. In that case that should be the logical structure.

We have a situation where we have several projects, some on branches, which frankly is too impractical to keep in the same workspace - and working sets are a joke. Unfortunately. Also having projects open you do not use, may accidentially be chosen from completion menues, etc. Error prone.

The really nifty feature for us, was when Team -> Project Sets were added (in Eclipse 3.3 I believe) as this allowed us to have a single file describing the many projects making up the whole application, which can be imported in Eclipse with Team->Import. Need a given project? Check it out of CVS, locate the projectSet.psf file inside of it, and import THAT.

This has proven to work well for us.

I have one workspace per Type of project. Ex: Plain Java, Web Application, Python etc.

The reason being I can share libraries that are similar without copying or pointing to them. Also, I close the unrelated projects from eclipse to avoid clutter.

I have all my projects in single workspace and use working sets to manage them.

Up to you! I've always found keeping the related versions of different projects, which belong to the same release in a given workspace a cleaner approach. That way, I could switch between workspaces whenever I need to refer to something in a separate release, and switch back to the current release workspace. It also saves me from the hassle of checking-out, or browsing the repository.

You may also want to keep in mind that you can open multiple instances of eclipse as long as they are looking at different workspaces. Not sure if that is important to you, but I like doing that from time to time.

I like to use several decoupled workspaces (which differ depending on the type of project), which import projects from various locations. Easy to move things around, without creating a ton of similar workspaces. Plays nice with my SCM too.

Depends on how many projects do you work?If you work on many projects, I'd use same workspace, because if you use several you can easily forget what is where and that can be frustrating to say at least. However I always use different workspace for different programming languages that way its less confusing, when you're in JAVA workspace you think JAVA :D