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  |
 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 #699014 is a reply to message #695313] |
Wed, 20 July 2011 16:28  |
David M. Karr
Messages: 813
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.
|
|
|
Goto Forum:
Current Time: Sun Nov 10 19:48:48 GMT 2024
Powered by FUDForum. Page generated in 0.02649 seconds |
] 
Search
Help
Register
Login
Home
