Deploying a custom eclipse package

Question

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:

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

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

score 1 · Answer 1 · answered Nov 08 '11 at 13:14

1

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.

answered Nov 08 '11 at 13:14

unbeli

301
1
3

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 08 '11 at 13:35
oh, you should not have your workspace in there! Workspace is totally personal. – unbeli Nov 08 '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 08 '11 at 13:43
true, but that can be safely ignored. – unbeli Nov 08 '11 at 13:49
OK, thanks. I'll try it and report back with any problems. – Mr Shark Nov 08 '11 at 14:18

score 0 · Answer 2 · answered Nov 08 '11 at 14:32

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 09 '11 at 08:00

Deploying a custom eclipse package

2 Answers2