What would you consider good Eclipse support?

Question

Hey,

As part of my job, I'm employed to install and support development tools for the developers in the company.

Eclipse is an IDE that a great deal of developers here use, but I don't actively support. With the huge range of plugins and quick release of new versions - I find it hard to keep on top of and would not be able (obviously) to support everything.

I do have some experience in Eclipse, but as a developer - what would you consider good support from your workplace in terms of Eclipse?

Thanks

Answer 1

1. Private, in-house plugin central. You are responsible for updating this repo and testing plugin updates first for currently developed projects - so devs do not need to worry about compatibility; they'll just update from in-house plugin repo.
2. Common settings, eg. coding style formatting defined and maintained.

Answer 2

At my workplace, Eclipse was the standard development tool, with projects released to compile with Eclipse (I was there when we discovered that the Makefiles didn't do anything if Eclipse hadn't already done the build). The simple solution is consider the developers need and provide them with the basic environment they need. Custom plugins can be installed in the home folder by developers themselves with a "no support" disclaimer. Just install the basic environment most people in your workplace need, and most common plugins. Say: - The base environment JDT - Graphical development/network development/C++ development plugins, or whatever you need for - Some UML plugin, if one is clearly better - Some profiler if you can get it to work (I've done profiling with Netbeans, gprof, even Oprofile, but I was never able to make it work with Eclipse - it's anyway more complicated to do profiling than in Netbeans). And if people use it. If people don't, something maybe needs to be reconsidered, unless no optimization is done at all because it's not needed :-). That's the only thing that people would need support for, IMHO, the rest has been transparent to use for me. - Maybe, on Linux, I'd like RPMs for gcj-compiled versions of Eclipse, like Ubuntu and RedHat provide. Except that I have no evidence that it is faster, while I have evidence that ecj (the standalone Eclipse Java compiler) itself is much slower with GCJ (and there are a lot of reasons why this is normal)!

Answer 3

A teamwide install, with a standard set of plugins.

Allow users to install new ones, and suggest new ones to be put into the standard install, but they should be aware that these are not supported.

Your lead developers will also have some idea about what configuration of these plugins will be helpful to be teamwide - e.g.

• SVN settings,
• Mylyn integration
• code styles
• checkstyle settings
• find bugs settings

Both install and plugins can be preprepared and distributed as a big zip file, or a more flexible approach would be to run your own update site internally.

Answer 4

About the different versions of Eclipse, just stick with a stable one and go with it. In a year or so, support a newer version following Marcin's advise.

Answer 5

I do (amongst other things) precisely that job.

I came up with a big zip file with:

• a stable eclipse version
• a few plugins recognized by developers as useful (Subclipse, QuickRex, Findbugs, Checkstyle with a common settings, ...)
• three JDK (!): 1.4, latest1.5, latest 6.0 (used to launch eclipse)
• a shell with aliases (includes 'e' to launch eclipse)

The script used to launch eclipse:

• has carefully tuned eclipse.ini settings
• check if new versions of my tools/scripts/files/plugins are published (on a common shared directory) and, it they do, copy them on the user's desktop.

That way my all "development configuration" evolves whenever I validate a new stable set of tools.

Basically, there is no need to install/update every plugins out there: just define a common core set of tools you and your colleagues are actually using on a daily basis.

Answer 6

Personally I'd like an internal update site with the "standard" plugins in a single entry. This is due to the wide array of possible Eclipse versions available, where nobody can cater to the needs of skilled developers in advance.

A common distribution as a zip-file with the internal update site and the "standard" plugins installed plus any source repositories defined (and the steps carefully defined), would be suitable for most developers without burdening you too much.

Answer 7

For a standard set of plugins and to keep up to date I configured a profile with Yoxos.