Reputation: 433
Is it possible to have several installations of Eclipse (with required plugins installed) in sync? If so, what would be the preferred approach?
I am looking for a way to keep Eclipse installations (one on desktop - Wind7 64 bit, another on laptop Win7 64 bit) with the required plugins installed, in sync. Ideally, I would like to exclude the runtime generated files from the sync process. I don't have an exhaustive list of files/folders to exclude but that is the next challenge.
I tried putting one install into a local git repo, then pushing this to a remote repo, followed by cloning from the repo onto the other location. I couldn't launch the cloned instance of Eclipse. I get this error :: http://pastebin.com/BpttUgvG
Versions of interest: Helios, Indigo
I have attempted the following without success
Any suggestions would be gratefully welcomed.
** EDIT ** Is it possible to do this without having to purchase additional software?
Upvotes: 3
Views: 513
Reputation: 34016
You know how I do it ? I drop the eclipse install folder in my Dropbox. Boom - absolutely synced*. That is for the same OS. If you want different OSes might work but haven't tried it. Maybe you could setup junctions/hard links to the plugins
, features
and configuration
folders, drop those in DB and bug(zilla) them if it doesn't work. Jars should be OS agnostic. See here for my efforts to keep workspace settings in sync. See here for the pecularities of comparing eclipse installs with identical plugins
EDIT : you can selective sync out folders in Dropbox - although there is no easy way to automate it, for a couple computers is not a huge pain
* : same goes for the firefox profile and this is OS agnostic. Same for most of my settings. Gosh if they suspend the free accounts I'll have to pay them
Upvotes: 0
Reputation: 10654
I use a script to set up my installs the exact same way on multiple computers. Eclipse comes with the p2 director, which can be used from the command line to install and update plugins.
For example, I download and untar my eclipse-SDK-I20110607-0800-linux-gtk-x86_64.tar.gz
and then use the director to load my standard set of features:
bash$ eclipse/eclipse \
-application org.eclipse.equinox.p2.director \
-noSplash \
-repository \
http://download.eclipse.org/egit/updates-nightly,\
http://download.eclipse.org/eclipse/updates/3.7,\
http://download.eclipse.org/releases/indigo \
-installIUs \
org.eclipse.egit.feature.group,\
org.eclipse.egit.source.feature.group,\
org.eclipse.jgit.feature.group,\
org.eclipse.jgit.source.feature.group,\
org.eclipse.emf.sdk.feature.group,\
org.eclipse.xtext.sdk.feature.group,\
org.eclipse.releng.tools.feature.group
The director can also be used to update an install, although non-intuitively by uninstall and then re-installing the same feature in the same call.
EDIT:
For a set of IUs you can keep each install up to date using uninstall/re-install in the same director call ... if there's an update available:
bash$ eclipse/eclipse \
-application org.eclipse.equinox.p2.director \
-noSplash \
-repository \
http://download.eclipse.org/eclipse/updates/3.7 \
-uninstallIU org.eclipse.sdk.ide \
-installIU org.eclipse.sdk.ide \
I don't think you can use this approach just yet, as you need to avoid bug 368238
The director won't effect most settings (formatting, keybindings, etc) as they're workspace scoped (INSTANCE) preferences. Some like formatting or code templates can be turned into project scoped preferences, and then saved in the SCM with the rest of the project information. There are hacks as well to copy workspace scoped preferences to every new workspace that you create.
Upvotes: 1
Reputation: 919
You can use this simple ant script: https://github.com/shajra/provisioning-java to automate the following:
So you can maintain a single source for your eclipse configuration and automate the install and configuration process.
Upvotes: 0
Reputation: 8310
Have you tried Pulse OneInstall Agent? It is meant for this purpose. They claim that using their tool:
you and your team can retain configuration records in code repositories (such as CVS), easily update tool configurations and have behind-the-firewall control of your tooling recipes
Upvotes: 0