I used to have many Eclipse installations in my machines; typically they were different Juno versions downloaded from ecipse.org, for instance, Eclipse for RCP developers, Eclipse for DSL developers, Eclipse Modeling Tools, etc. Moreover, most of them were customized with the same plugins (for instance, Mylyn connectors) which I had to install on all of them. I preferred to have separate installations not to have a monolithic single Eclipse instance (where some features might also interfere with each other).
Then I started to use the ability of Eclipse to deal with multiple configurations, which is really a cool feature.
The idea is that you have a single Eclipse installation with all the features you always used and that you would desire in all of your Eclipse installations; then you have different directories for each “configuration”.
You can start Eclipse with a command line like the following, which uses the command line argument -configuration:
|
1 |
eclipse-main/eclipse -configuration eclipse-other/configuration |
Assuming that the main Eclipse installation is in eclipse-main directory, and that the new separate configuration will be stored in eclipse-other/configuration (which will be automatically created if it does not yet exist). What you get is a running Eclipse instance with all the features and plugins of the main Eclipse installation, but all the new features which will be installed from this running instance will go in the new configuration, thus they won’t disturb the main installation!
If you try to install new software from this Eclipse running instance, you’ll see that the list of available software sites is empty, so you will have to fill such list with the typical Eclipse software sites, such as http://download.eclipse.org/releases/juno and http://download.eclipse.org/eclipse/updates/4.2.
And then you can install new features in this Eclipse, and they will be available only in this configuration. You can then check the plugins and features directories in eclipse-other which will contain the new installed features and bundles (which will not be stored in the same directories of eclipse-main); similarly, the plugins and features directories in eclipse-other will not contain the features and bundles which are stored in the same directories of eclipse-main, though they are available in the new Eclipse configuration.
Of course, you’ll have to use the above command line each time you want this Eclipse version (you should have shell scripts to run a specific Eclipse).
Main advantages in this approach are
- The features you want to use in all configurations are stored in only one place, and they will be maintained only in the eclipse-main installation (e.g., kept up to date)
- you save some space in your hard disk (I had 4 Eclipse installations which required 2.5 Gb; with the new approach, i.e., one Eclipse main installation and 3 configurations I only need 500 Mb!)
If you can still use command line to install new features in the separate configurations (I blogged about that); you just need to adjust the command line with the -configuration parameter.
For instance, to have an Eclipse configuration in eclipse-texlipse/configuration (based on the main Eclipse installation stored in eclipse-main) with the addition of Texlipse and Subversion features I run these commands
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
./eclipse-main/eclipse \ -configuration ./eclipse-texlipse/configuration \ -application org.eclipse.equinox.p2.director -noSplash \ -repository http://download.eclipse.org/releases/juno,http://download.eclipse.org/eclipse/updates/4.2,\ http://texlipse.sourceforge.net/ \ -installIUs \ net.sourceforge.texlipse.feature.group,\ de.vonloesch.pdf4eclipse.feature.group \ -vmargs -Declipse.p2.mirrors=true -Djava.net.preferIPv4Stack=true ./eclipse-main/eclipse \ -configuration ./eclipse-texlipse/configuration \ -application org.eclipse.equinox.p2.director -noSplash \ -repository http://download.eclipse.org/releases/juno,http://download.eclipse.org/eclipse/updates/4.2 \ -installIUs \ org.eclipse.team.svn.feature.group \ -vmargs -Declipse.p2.mirrors=true -Djava.net.preferIPv4Stack=true |
Note that using the command line for installing new features will also store in the Eclipse configuration the specified update sites (so you will find them in the Install New Software dialog).
Hi Lorenzo, thanks for posting this. I was looking for some functionality like this, but wasn’t aware that its already there!
Andreas, I think it’s been there for a long time but honestly I had never heard of it myself 🙂
As usually there are also some disadvantages:
1. Eclipse runs noticeable slower when main installation is placed on a server. The best example is Run/Debug Configuration dialog. Opening it locally is rather slow and opening it in such configuration takes ‘ages’.
2. Some plug-ins do not work when installed in separate configuration. They must be installed within main installation. I spent a lot of time to find the reason but I did not find any clues.
Dariusz, can you please list some of these plugins which do not work when installed in separate configuration?
In my project ITS there are two plug-ins reported: SWTBot and QuickRex but I am sure there are more of them. After some time of trying to make them work we just gave up. When we encounter similar plug-in we just install it within main installation.
Since I’m using SwtBot most of the time, it is installed in my main eclipse, that’s why I haven’t experienced that problem I guess 🙂
There is one more possibility to share locally common set of plug-ins. It is called a ‘Bundle pooling’ (http://wiki.eclipse.org/Equinox_p2_Getting_Started#Bundle_pooling).
This is only a hint. I never try it.
I’ll have a look 🙂
I am facing problem in my eclipse whenever I am trying to change my build path it shows some error. What should I do?
Does this have anything to do with this post?
If so, you should detail the problem/error you have if you want someone to help you…
Pingback: Mise en place d'un environnement Eclipse Bash
Hi Lorenzo,
i read your post and this is exactly the same solution that i adopted until now. About this post i have a couple of questions for you:
1) since you tested this kind of solution, can you say if, in your opinion, this is equivalent to “Scenario 2” as documented in Eclipse Help (Multi-User Installs)? If so, how would i implement the “Scenario 3”? You consider that really i would like to share common plugins between configurations but i wouldn’t want to touch the main installation area …
2) some days ago i opened a topic on Eclipse Forum (https://www.eclipse.org/forums/index.php/t/1070925/) about the advantages of the sharing configurations over bundle pooling. Really i’m not convinced that the bundle pooling is better. If you want, you can write your thoughts in my topic …
Thank you very much …
Ciao Pasquale
I stopped using multiple configurations: I found them quite unreliable (a few things did not work at that time, but I don’t remember which ones). Most of all, it’s hard to keep them up to date: when you update the main installation, the other configurations have to be updated (and again, I remember a few problems with that). I’m now a very happy user of bundlepools 🙂 especially with Oomph (see my recent post about the new Eclipse installer)
Ciao Lorenzo,
thanks for your reply. I have already read your post about Oomph and maybe that Oomph will be the definitive solution but i would like to know because the eclipse maintainers do not explicitly deprecate the old solutions. I see also in Mars help the same paragraph (Multi-user Installs) and even Pascal Rapicault in the Eclipse Forum claims that the two solution are orthogonal each other and may work together.
Very confusing to me …
In the end, my last question for you, have you ever realized what is the real difference between the Scenario 2 and Scenario 3 in Multi-User Installs?
Thank you very much.
Probably they don’t deprecate it because it is still used and it may also work… it did not work completely for what I needed, and, probably it was me that was using it the wrong way 😉
as for Scenario 2 and 3 I wouldn’t know… it looks like they differ only for writable areas?
Please suggest vmargs and other options to install TestNG plugin commandline.
I am getting below error:
“C:\\scripts>C:\\Apps\\eclipse\\eclipsec.exe -nosplash -application org.eclipse.equinox.p2.director -repository file:/C:/Apps/eclipse/org.testng.eclipse.updatesite -installIU org.testng.eclipse.feature.group,org.testng.eclipse.maven.feature.feature.group -vmargs -XX:MaxPermSize=1024m -Xms40m -Xmx1024m “,
05:50:52 “#”,
05:50:52 “# There is insufficient memory for the Java Runtime Environment to continue.”,
05:50:52 “# Native memory allocation (mmap) failed to map 41943040 bytes for Failed to commit area from 0x00000000c0000000 to 0x00000000c2800000 of length 41943040.”,
05:50:52 “# An error report file with more information is saved as:”,
05:50:52 “# C:\\scripts\\hs_err_pid8176.log”
This blog post is really old. Nowadays, there are much better and easier-to-use alternatives, like Oomph (the Eclipse installer): https://www.lorenzobettini.it/tag/oomph/. With Oomph you reuse common features and bundles, so you get the same benefits but in a more comfortable way. You might want to switch to that. Concerning the vmargs options, I can’t help. For sure, “-XX:MaxPermSize” it’s been deprecated since Java 8.