Home / server / Questions / 328872
In Process
Mr Shark
Asked: 2011-11-09 05:07:07 +0800 CST

Deploying a custom eclipse package

  • 772

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.

deployment eclipse

2 Answers

  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.

    • 1

  2. 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.

    • 0