Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » How to achieve lightweight workspaces(Switch between multiple project SCM branches easily by combining best of workspaces and working sets)
How to achieve lightweight workspaces [message #695313] Mon, 11 July 2011 13:31 Go to next message
David Biesack is currently offline David Biesack
Messages: 9
Registered: July 2009
Junior Member
Is there the platform concept of "lightweight workspaces" in Eclipse - something between workspaces and working sets? Explanation: We use CVS for our source management, along with Maven or Ivy dependency management. I want to set up a "lightweight workspace" for a set of tightly related projects in branch A, and another "lightweight workspace" for the same set of projects in branch B. I want to share most workspace settings: project dependencies, perspectives, JVM's, keys, launch configurations, JUnit launch history, etc. The "Copy Settings" in the Workspace Launcher is not comprehensive.

Then, when I want to switch from working in one CVS branch to another, I would like to simply switch between these lightweight workspaces more quickly that Eclipse can now switch between workspaces. Basically, this entails associating new source locations for the various projects. I.e. the source for branch A, projects P1, P2, P3 may be in ~/dev/brances/A/P1, ~/dev/brances/A/P2, ~/dev/brances/A/P3 . I'd like to invoke a "File -> Switch Lightweight Workspaces" operation that keeps the same projects P1, P2, and P3 but resets their project locations to ~/dev/brances/B/P1, ~/dev/brances/B/P2, ~/dev/brances/B/P3 . Later, I might want to add a new lightweight workspace for branch C and simply add the new project locations, ~/dev/brances/C/P1 etc.

Working sets (one for each branch, for example) don't achieve this: they don't let me have two projects of the same name in the same workspace. Also, I can't reuse launch configurations across those sets, and the workspace would become unmanageable with more than 2 branches.

I know I can import/export things like workspace preferences, perspectives, launch configurations, but that a real hassle, and still incomplete (i.e. I lose JUnit launch history, etc.). I just want more native support for to switch branches (i.e. project locations) across multiple projects.

I don't think such support yet exists, but if there is a project related to this, or a couple feature requests/bugs, please point them out so I can vote on 'em. If not, I'll submit this idea a a feature request.

Related bugs which don't quite match: 318670, 191746
Re: How to achieve lightweight workspaces [message #698010 is a reply to message #695313] Mon, 18 July 2011 15:36 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

With CVS, the two ways to switch your projects so you can work on a new branch are the ones you've found already:

1) heavy weight workspace switch
2) Team>Replace With>Another branch or version

With #1 you have to do the work to keep your preferences in sync. Option #2 will give you the shared prefs functionality you want, at the largest price: time it takes to replace all of your projects from CVS.

This kind of thing is one of the reasons the Eclipse project itself is switching to git (not necessarily an option for some projects, but worth considering). Git provides the quickest implementation of "just switch to another branch".

PW


Re: How to achieve lightweight workspaces [message #699014 is a reply to message #695313] Wed, 20 July 2011 16:28 Go to previous message
David M. Karr is currently offline David M. Karr
Messages: 354
Registered: July 2009
Senior Member
I would do this with a combination of elements, both within Eclipse and outside of it.

You can use Mylyn task contexts as your "lightweight workspace". When you're working on one task, your context is limited to the projects associated with that task, which affects both the project/package explorer and the tabs in the source view.

In my work environment, I have a similar problem. Our "application" consists of about twenty separate Eclipse projects, and we're working on this on several branches, often at the same time. Several projects will be on one branch, several on another, and often on multiple branches. Many of these projects have dependencies on each other.

Our build script unfortunately requires that we check out each of these projects with their original name. That means if I want to build the entire application from Eclipse, I can only check out one version of each project. I concluded that I didn't want to be limited to that, and I also felt that I don't have to build the entire application that often.

When I check out projects, I check them out as "originalname-branchname". I do this consistently. When I first started doing this, I started manually changing the build path dependencies to point to the projects with the same "-branchname" suffix. That got old real fast.

I then decided to build an external tool that manages much of this for me. I wrote a Java class that reads an XML configuration file (using Commons Digester) which specifies the build trees I want to manage. Each build tree element specifies a root directory on the drive to create the build tree, and a workspace directory where the "target" projects live. I also specify a default branch name, and a list of projects with a "basename" and an optional branch name.

When the tool runs, it creates the build tree directory, and in that directory it creates symbolic links (or junctions on Windows) to each of the projects specified in the build tree element, where the link name is the "basename", and it links to the project with the appropriate branch name suffix.

The tool also knows what the ".classpath" file looks like in each project, and it knows what changes it has to make to fix the project dependencies in Eclipse.

After I've run the tool, I can run the application build from the build tree directory, and in Eclipse (after I refresh), all the compile errors from missing depenencies are gone.

You could even use "team project sets" to import an entire set of projects with a specified branch in a single step.
Previous Topic:How to run import project wizards from headless mode
Next Topic:Plugin Version Mismatch Issue
Goto Forum:
  


Current Time: Thu Oct 30 19:08:05 GMT 2014

Powered by FUDForum. Page generated in 0.04184 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software