I’ve been an Eclipse user since somewhere around 2002 and one of the things that has really annoyed me over all of that time is how hands on managing the IDE’s environment has been. I dreaded having to switch out computers or start all over with Eclipse when I changed jobs. It was back to the find and install plugin mambo each and every time. It appears that there are some new tools on the horizon that are trying to help developers in just this situation. Each of them tries to ease the developers life a little bit by taking away the pain and agony of setting up Eclipse.
Each of these tools is a little bit different and I’m not trying to review them per se. This is more of an introduction for those that might not be familiar with some of the options out there. Now I know that some other nameless IDEs have had plugin management built in for a while (I’m looking at you IntelliJ IDEA) but Eclipse has not.
EasyEclipse is a distribution of Eclipse like Ubuntu is to Linux. They have different packages of open-source plugins targeted to specific development needs. For example, they have Desktop Java, Server Java, and Mobile Java distributions. I’ve used various EasyEclipse distributions in the past and I’ve found them easy to install and rock solid. I suppose the only thing I don’t care for is that lately they don’t seem to be keeping up with the latest versions of Eclipse or the bundled plugins. But if you’re don’t care about being on the latest greatest then that might not matter to you.
Pulse is what I’ve been playing around with recently. It is a service that allows you to create profiles of Eclipse add-ons and have them downloaded automagically to your machine. When you have to move to another machine you simply install the Pulse software, login, choose a previously created profile and let it setup Eclipse with all your selected add-ons ready to go. I like that it is easy, very quick to get going, and has a fantastic interface (including a “Pulse Explorer” within Eclipse itself). The downside is that it is a new service in beta and there are a few annoying gotchas (i.e. currently you can’t switch workspaces without shutting down Eclipse and selecting another workspace). The repository is a bit on the small side but the developer Genuitec looks like they’re really working to expand the add-ons selection.
Yoxos is a Eclipse add-on distribution service that is a plugin to Eclipse. You really have to try their Yoxos On Demand to see an amazing web demo. Yoxos uses its web interface as the starting point (as opposed to Pulse’s executable) but after that you interact with the Yoxos interface within Eclipse itself. The plugin selection they have is easily the best and most wide ranging of the ones mentioned here.
I do wish that any of these services would allow me to upload my own Eclipse preferences files and attach them to my account so that they could follow me around too. (hint, hint, big money to be made here)
Over the long haul I think Pulse is going to have the biggest impact. I’m not saying the other guys don’t have their place but seeing how well Genuitec’s MyEclipse has been managed these folks know what they’re doing. I do wonder how they plan on making any money off of Pulse without charging people to use it.
stephan responded on 16 Dec 2007 at 9:17 am #
Hi!
I have checked pulse from your recommendation, it seems to solves lots of my day-per-day problems with eclipse. I has a lot of potential.
Thanks
stephan
Chris responded on 16 Dec 2007 at 9:56 am #
That’s great, Stephan! Keep in mind that Pulse is still in beta and has a few rough edges (like the one I mentioned above). If you decide to use a while why not come back and gives us your impression?
Thomas Ehardt responded on 16 Dec 2007 at 10:11 am #
Why not just use link files?
See Method #3 here: http://www-128.ibm.com/developerworks/opensource/library/os-ecl-manage/
I have my eclipse directory in one location, my plugins in another, and my workspaces in another; this makes it very easy to drop in a new version of eclipse and/or test plugins.
Just a thought; I do like the way Pulse works though.
Xappa responded on 16 Dec 2007 at 11:25 am #
I tried Yoxos in the past. Its value add over installing the plugins myself was minimal at best. When their server is down, which does happen from time to time, Yoxos is a detriment, not a benefit.
This entire ‘market’ will disappear once plugin management becomes part of Eclipse itself — which will hopefully be soon.
Plugin ‘management’ aside, the biggest issue with Eclipse plugins is that a lot of them are low quality and do not work reliably. For instance, I still to this day do not know which subversion plugin is trustworthy. Or which Maven plugin works at all.
The fact that many plugins do not work well is far more frustrating than managing the plugins themselves.
Blog do Márcio d’Ávila » Artigo Eclipse 3.3 atualizado responded on 16 Dec 2007 at 3:27 pm #
[…] também o artigo How to Manage Your Eclipse Add-Ons Painlessly (em inglês), por Chris Grok, […]
Chris responded on 16 Dec 2007 at 4:27 pm #
Thomas,
Those IBM tips work fantastically for managing Eclipse’s plugins on a single box but I often like to have the same Eclipse configuration across different physical machines. For example, I am about to have to change out development boxes at work and simply want my environment up and running as fast as possible. Using the above three tools I can have the add-ons I’m used to without having to even remember which ones I’ve installed (given that those add-ons are in one of the repositories).
Do you do some thing different that the IBM article didn’t go into?
napyfab:blog» Blog Archive » links for 2007-12-16 responded on 16 Dec 2007 at 5:29 pm #
[…] Grok Programming » How to Manage Your Eclipse Add-Ons Painlessly (tags: eclipse manage addon plugin development ide programming) […]
Thomas Ehardt responded on 16 Dec 2007 at 8:43 pm #
Yes; I came up with a standard development environment for developers on my team, and I’ve broken things down like this:
/devenv/eclipse-3.2.2 ==> eclipse 3.2.2 installation
/devenv/eclipse-3.3 ==> eclipse 3.3 installation
/devenv/eclipse-workspaces/eclipse-3.2.2 ==> workspace for eclipse 3.2.2
/devenv/eclipse-workspaces/eclipse-3.3 ==> workspace for eclipse 3.3
/devenv/eclipse-plugins ==> root dir for plugins
/devenv/eclipse-plugins/MyEclipse/5.5 ==> MyEclipse 5.5 files (for eclipse 3.2)
/devenv/eclipse-plugins/MyEclipse/6.0 ==> MyEclipse 6.0 files (for eclipse 3.3)
/devenv/eclipse-plugins/Subclipse/1.2.4 ==> latest version of subclipse
/devenv/eclipse-plugins/pmd/4.1 ==> latest version of pmd
Using the version numbers for the plug-ins makes it easy to try a new version and backout if it has bugs.
Within each eclipse installation, I have a links directory:
/devenv/eclipse-3.2.2/links
/devenv/eclipse-3.3/links
where the links directory contains files named *.link that have the path to the plug-in (I like relative paths, and it works for 3.2 and 3.3). For example, for Subclipse 1.2.4, I have a file “subclipse-1.2.4.link” with the following content:
path=../eclipse-plugins/subclipse/1.2.4
(It took some trial and error to find that the path is relative to the eclipse executable and not the links directory)
Now, if Subclipse comes out with a 1.2.5 release, I would unzip the distribution to the appropriate eclipse-plugins subdirectory, and then create a new link file.
In writing this, I realize that it sounds like a lot more trouble than it is worth, but I find that it has made life a lot easier; one of the very few things that I don’t like about eclipse is that there’s no good “uninstall plugin” feature. Using the approach above, the eclipse installations are kept as close to the original installation as eclipse lets them.
Now … as for duplicating across multiple machines, I find it’s a matter of just doing a copy of the entire devenv directory from one machine to another. When an entire team is using this method, it becomes very easy to identify differences between eclipse installations.
The benefit that this approach has over pulse is that I can use whatever plugins I want; if/when pulse lets me specify my own plugins, I’ll probably consider moving to it for good.
The benefit that pulse has over this approach (and I admit it is a big one) is that you can set up multiple profiles for a single installation of eclipse; if I want one profile that is eclipse + myeclipse, I can … then one that is eclipse + subclipse + mylyn, it can manage that without having to have a second installation of eclipse on the machine.
Add to this the ability to use junctions (in XP) and links (in Linux, and I assume OSX), and one could switch out the version of java that eclipse uses very easily (re-link or re-junction the eclipse/jre directory).
I think it all comes down to personal preference; in my situation, it’s nice to have the “copy and paste” (well, really, “unarchive”) method for creating a new build environment, whereas in your situation, this may be more trouble than it’s worth.
regards,
Thomas
Chris responded on 17 Dec 2007 at 7:48 am #
That is a excellent way of setting up a dev environment! Do you have a universal Eclipse setup for your company? If not, how do you handle different project groups needing different Eclipse configurations? Sadly, the company I work for isn’t very sophisticated in its development processes (a few of us here are trying to change that) so we have wildly different Eclipse needs per project.
You do point out one of the biggest drawbacks to all of the automated tool/services, if the add-on simply isn’t in the repository at all you lose all the benefit of the tool or service. I suppose eventually giving companies the ability to setup a repository of add-ons that can pull from the default central add-on repository would get around that (sort of like setting up a company Maven repository).
I don’t understand why Eclipse makes it a pain to get rid of a plugin. I know you can disable one but then, as far as I can tell, you have to run off to the file system to actually remove to from Eclipse. Maybe I’m simply missing something here (I hope so).
Seriously, you should try to get an article published about your setup. I learned a few tricks and ideas just from your comment.
Chris responded on 17 Dec 2007 at 7:56 am #
Xappa,
I agree there are tons of Eclipse add-ons of dubious quality out there. It is a sad result of programming in the commons.
I believe Pulse is built on top of the Eclipse Maynstall (http://www.eclipse.org/maynstall/) framework. I think any serious companies trying to deliver this type of service should conform to Maynstall just like they have to for the plugin framework.