Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

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.

share|improve this answer
    
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.

share|improve this answer
    
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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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