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.

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.

/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

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?

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.

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.

Thanks
stephan