5

I have a eclipse workspace which constitutes of 15 different java projects . To configure the eclipse workspace , every time I need to add the java projects manually and add the dependency and refrences in the java build path. Adding all the projects and resolving dependency every time becomes a manual and redundant task. I explored on the .classpath inside the every projects which stores the dependency and refrences information. I would like to automate this redundant process. Have any one tried doing that , any inputs will be helpful.

I don't need to add same project more than once , but often need to create a new eclipse workspace with new code changes and delivery (I can't take some of the changes in the current work space).In simple terms for e.g if some one need to create eclipse workspace again and again , or multiple people need to create the same workspace for their work . How can we reduce that manual effort?

Kara
  • 6,115
  • 16
  • 50
  • 57
auto26
  • 53
  • 1
  • 5
  • when you need to do this??.. on a new machine ??? – sudmong May 17 '11 at 07:04
  • Could you elaborate why you need to add the same project more than once? – Jacob May 17 '11 at 07:05
  • I don't need to add same project more than once , but often need to create a new eclipse workspace with new code changes and delivery (I can't take some of the changes in the current work space).In simple terms for e.g if some one need to create eclipse workspace again and again , or multiple people need to create the same workspace for their work . How can we reduce that manual effort ? – auto26 May 17 '11 at 10:34
  • just wanted to say, i completely understand this problem. we have this situation many times at work, like when you switch computers or have new employees you have to reimport all the projects over and over again. – clamp May 17 '11 at 11:30

6 Answers6

1

Maybe little late, but stuck into the same problem and found a tool in eclipse marketplace that helps to manage setting up and launching eclipse all time for different branches, new developers or other reasons. The tool is called yatta.

With this, one can create profiles which can be based on their current running eclipse with all the tools, plugins, workspace, CSM repos and what not.

This profiles can be exported to yatta profile hub which can be public or private and later shared with different developers and can be imported and launched.

Muzzammil Ayyubi
  • 53
  • 1
  • 2
  • 11
1

I am still a little unsure about your motivations but I am going to assume that by new code changes and delivery you mean a different revision/branch of the same code base. For this purpose and for many other reasons, if you are not using source control like SVN or Git, look into it. These tools are priceless and also free.

Eclipse

I don't think this is technically part of your question but I wanted to add it for completeness. If you're implementing the techniques below, it is also handy to have a 'fully loaded eclipse'. I keep a 'fully loaded eclipse' on a network drive somewhere with some plugins pre-loaded so that new additions to the team don't have to download/install the plugins. It's not hard to do since eclipse doesn't need to be 'installed'. You can just copy the eclipse folder to where you want it and run it. Personally I like to include plugins for source control, code style, code coverage and metrics but you should include anything that you use consistently in your project.

The Workspace

To copy an existing workspace (not including any projects, I'll get to that later) all you have to do is copy the .metadata folder from an existing workspace folder to an empty folder that will be your new workspace folder. When you start up eclipse simply choose the new workspace folder and you will have all the same preferences as you had in the other workspace.

I have used this technique before so that when people join a project they can take a copy of a 'clean workspace' I keep on a network drive somewhere that helps them get up and running quickly. Preferably, this 'clean workspace' should not have any preferences that are only personal preferences like having the perspectives setup just the way you like it but should only have preferences like Ant global properties, compiler compliance level, pre-made commonly-used external tool and run configurations etc.

Projects

For the projects themselves, I would recommend checking them into source control including the eclipse .project and .classpath files. The SVN plugin (subclipse) makes it very easy to do this. Then when someone joins your project, all they have to do is check them out as projects in their new 'clean workspace' which is also very easy to do. Since the project you're checking-out already has the .project and .classpath files, all of the dependencies are already setup! Just make sure that all the jars and any other dependencies are checked-in with the projects.

Workspace Setup Procedure

  1. Take a copy of the 'fully loaded eclipse'.
  2. Take a copy of the 'clean workspace'.
  3. Check out the projects into that workspace.

That's it! Your new recruit should be ready to go!

Multiple Code Branches

Now, if I was right to assume that by new code changes and delivery you mean a different branch of the same code base, creating a workspace for a different branch as easy as following the same steps but checking out the required revision or branch instead of the latest version from the trunk. If you don't quite understand what I mean by that, read up on source control.

Cudos

Good on you for taking the time to do this, I have been in projects where it can literally take a day to get setup...

Gyan aka Gary Buyn
  • 12,242
  • 2
  • 23
  • 26
  • @Anon Agreed. It is always best to also have ways of building your projects outside of eclipse. This is required for [continuous integration](http://martinfowler.com/articles/continuousIntegration.html). – Gyan aka Gary Buyn May 17 '11 at 11:51
  • @Gary thanks for sharing the info .It gives me good place to start. I am using Rational Clearcase for source control and I use snapshot views where the source files are copied in to the users machines. So I need to explore more on.. 1) How to modify the .classpaths for each project to update the dependency.I think I know how to do that.2) How can I load the projects to the workspace . Presently I manually add the java projects pointing to the snapshot view created . – auto26 May 18 '11 at 08:54
  • @auto26 Happy to help. 1) If you include the entire project folder including the .project and .classpath files in source control you should never have to modify them manually. 2) You just need to checkout the project folder (again, including the .project and .classpath files) to your local machine and import it using the eclipse import project wizard. – Gyan aka Gary Buyn May 18 '11 at 10:49
  • @auto26 I am not familiar with Rational Clearcase terminology but I think what you're calling a _snapshot view_ is, in general source control terms, a _working copy_. Check out [this wikipedia article](http://en.wikipedia.org/wiki/Revision_control#Common_vocabulary) if you are not familiar with the general terminology. I have tried to use the general terminology consistently. – Gyan aka Gary Buyn May 18 '11 at 10:53
  • @Gary Snapshot view can be described in simple terms as ...it crates a copy of the source files in the user machines. I tried to checkin the .project and .classpath files in to source control . But the challeneg with this approach is that every user creates the snapshot view(copy of the source files ) on their machine at path which is not predefined . In the .classpath files the paths are quite important which can be changing due based on the user machines. – auto26 May 18 '11 at 14:22
  • @auto26 Yeah that definitely sounds like a _working copy_ i.e. a copy of the files for you to work with. Do you use absolute paths in your classpath? This should not be necessary if all of your dependencies are also in your projects, which they should be. I use this technique at work and I have checked out the same projects on Ubuntu and Windows where the paths could obviously not possibly be the same without any need to change .classpath. – Gyan aka Gary Buyn May 18 '11 at 19:49
0

Using vagrant it is quite easy to automate setting up an entire desktop development environment.

See the answer I provided to a similar question here, which has links to scripts that automate checking out maven projects, creating an eclipse workspace and importing the projects.

Community
  • 1
  • 1
Chris Snow
  • 23,813
  • 35
  • 144
  • 309
0

You don't say whether you're using a build tool other than Eclipse, but if not you should.

Eclipse is able to parse Ant files to discover the source directories and libraries. And Maven and Gradle can both generate Eclipse project files for you to import.

As a longer-term benefit, using a build tool means that you can easily build and deploy your projects without any need for Eclipse. And it will be easier for new team members to work on the projects, as they won't need to figure out all the dependencies.

If you don't already have people with expertise, I would recommend Maven. It's easy to set up a basic Java build script, and its dependency management features are IMO better than the alternatives. It will, however, force you into its way of doing things, particularly wrt source tree layout.

Anon
  • 2,328
  • 12
  • 7
  • I need to explore more on.. 1) How to modify the .classpaths for each project to update the dependency.I think I know how to do that.2) How can I load the projects to the workspace . Presently I manually add the java projects pointing to the snapshot view created . Regarding Maven I need to explore more on this . Sounds like good stuff to learn. – auto26 May 18 '11 at 08:58
0

You should really look into build tools like Maven, Ant, .... Those can generate needed classpath variables for you automatically and can do many more things as well

fmucar
  • 14,361
  • 2
  • 45
  • 50
  • need to explore more on.. 1) How to modify the .classpaths for each project to update the dependency.I think I know how to do that using Ant.2) How can I load the projects to the workspace . Presently I manually add the java projects pointing to the snapshot view created . Regarding Maven I need to explore more on this . Sounds like good stuff to learn. – auto26 May 18 '11 at 09:01
0

If you're checking out the projects from CVS / SVN in Eclipse, then it's possible to create a Team Project Set. This is essentially an XML file that will contain a list of projects and their source repository path

It can be exported via File | Export | Team | Team Project Set, and imported into another workspace via File | Import | Team | Team Project Set

There's more information on this feature at this link on Javalobby

mecsco
  • 2,250
  • 1
  • 15
  • 28
  • am wondering if Team Project Set would work only in case of is you source code repo at SVN or CVS. Am using Rational Clearcase and creating snaphsot views , which copies the source files on my machine. – auto26 May 18 '11 at 09:00
  • Cool. I didn't know about that feature but I'll be sure to check it out. – Gyan aka Gary Buyn May 18 '11 at 10:42