I'm planning to deploy eclipse to approximation 30 workstations running Ubuntu and would like to avoid a long list of settings/downloads that everyone needs to go through before they can start working.

The type of things I want to do:

  • Install some plugins (e.g. CDT, Subversive, nothing exotic)
  • Configure a default codestyle
  • Perhaps setting up some default remote hosts in RSE

My feeling is that I should be able to do this by simply:

  1. Configure an instance on my machine.
  2. Do some magic thing that removes the binding to my environment (paths etc.).
  3. Tar it up and distribute.

The problem is that I do not know what the magic is and can't find it.


Normally there is nothing in eclipse that binds it to the environment like paths and such (unless you deliverately introduce it, for example by specifying the path to JVM in eclipse.ini). Configuration is in the workspace, not in eclipse itself. I was bundling eclipse for my colleagues for some years, and it's as simple as ZIPing it.

  • Currently I have 63 instances of my username in my eclipse tree with resent workspace, cache handling etc. But perhaps it's ignorable.
    – Mr Shark
    Nov 8 '11 at 13:35
  • oh, you should not have your workspace in there! Workspace is totally personal.
    – unbeli
    Nov 8 '11 at 13:38
  • I don't but the path to the latest workspace is stored in ./configuration/.settings/org.eclipse.ui.ide.prefs inside of the eclipse install (as an example)
    – Mr Shark
    Nov 8 '11 at 13:43
  • true, but that can be safely ignored.
    – unbeli
    Nov 8 '11 at 13:49
  • OK, thanks. I'll try it and report back with any problems.
    – Mr Shark
    Nov 8 '11 at 14:18

If you were building this as a project bid contractor you'd need to define something that is reproducible.

  • A specific build and version of eclipse.
  • A specific build and version of Java.
  • Alternate tested versions of Java.
  • A specific set of install options, hardware reqs, kernel/os versions, directories, etc.
  • Install some plugins (e.g. CDT, Subversive, nothing exotic)
  • Configure a default codestyle
  • Perhaps setting up some default remote hosts in RSE
  • Test cases to validate install
  • Preferably script everything from download, to install, config and testing.


  • Package using archive and checksum.
  • Test Install Package
  • Deploy Package
  • Test and validate new versions, eclipse, java, os, etc. and update package version.

Zipping a used application directory could create a package that can't be easily reproduced and doesn't behave like a "standard" install.

Later, from your SCM, you should be able to build any version of the package to match a client's system or to debug a defect against a specific package version.

  • Yupp, approximately what I had in mind (minus the version choices, since the development platform is fixed in a virtual machine). Do you have a HowTo somewhere on the net that describes how I should "Package using archive and checksum."?
    – Mr Shark
    Nov 9 '11 at 8:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.