Geek Answers Handbook

What do you think is good support for Eclipse?

As part of my work, I am engaged in the installation and support of development tools for developers in the company.

Eclipse is an IDE that many developers use here, but I do not actively support it. With a huge set of plugins and a quick release of new versions - it’s hard for me to support and will not (obviously) be able to support everything.

I have some experience with Eclipse, but as a developer - what would you consider good support from your workstation from an Eclipse point of view?

+6
eclipse sysadmin
source share
7 answers

Nationwide installation with a standard set of plugins.

Allow users to install new ones and offer new ones that will be placed in a standard installation, but they should know that they are not supported.

Your lead developers will also have some idea of ​​which configuration of these plugins will be useful for teamwork - for example.

  • SVN settings,
  • Integration with Mylyn
  • code styles
  • Validation Style Settings
  • find error settings

Both installations and plugins can be pre-prepared and distributed as a large zip file, or a more flexible approach is to run your own update site inside.

+4
source share
  • Private central plugin. You are responsible for updating this repo update and testing plugins primarily for projects currently under development - so developers do not need to worry about compatibility; they will simply be updated from the internal plugin repository.
  • General settings, for example. coding style formatting is defined and supported.
+4
source share

I am doing (by the way) exactly this work.

I came up with a large zip file with:

  • stable eclipse version
  • several plugins recognized by developers as useful (Subclipse, QuickRex, Findbugs, Checkstyle with general settings, ...)
  • three JDKs (!): 1.4, latest version 1.5, latest version 6.0 (used to trigger eclipse)
  • shell with aliases (includes "e" to trigger the eclipse)

The script is used to run eclipse:

  • carefully configured eclipse.ini settings
  • check if new versions of my tools / scripts / files / plugins are published (in the general shared directory) and, as they do, copy them to the user's desktop.

Thus, my entire “development configuration” evolves whenever I test a new stable set of tools.

Basically, there is no need to install / update all plugins: just define a common set of tools that you and your colleagues use on a daily basis.

+2
source share

For a standard set of plugins and to maintain relevance, I set up a profile with Yoxos .

+1
source share

At my workplace, Eclipse was a standard development tool, with projects released to compile with Eclipse (I was there when I found that Make files didn’t do anything if Eclipse hadn’t completed the build yet). A simple solution is what developers need and provide them with the basic environment that they need. Custom plugins can be installed in the home folder by the developers themselves with a “no support” disclaimer. Just set up a basic environment for most people in the workplace and the most common plugins. Say: - The basic JDT environment - Graphic development / network development / C ++ development plugins or whatever you need for - Some UML plugin if clearly better - Some profiler if you can make it work (I did profiling with using Netbeans, gprof, even Oprofile, but I could never get it to work with Eclipse - it’s still harder to perform profiling than with Netbeans). And if people use it. If people do not do this, something may need to be reviewed, unless optimization is performed at all, because it is not needed :-). The only thing that people need support, IMHO, the rest was transparent to me. “Maybe on Linux I would like RPMs for gcj-compiled versions of Eclipse, such as Ubuntu and RedHat.” Except that I have no evidence that it is faster, while I have evidence that ecj (the standalone Java Eclipse compiler) is much slower with GCJ (and there are many reasons why this is normal)!

0
source share

About the different versions of Eclipse, just stay stable and continue with it. After a year or so, keep up with the new version following Marcin’s advice.

0
source share

Personally, I would like an internal update site with standard plugins in one record. This is due to the wide range of possible versions of Eclipse, where no one can satisfy the needs of experienced developers in advance.

General distribution in the form of a zip file with an internal update site and installed “standard” plugins, as well as any specific source repositories (and steps that have been carefully defined) would be suitable for most developers, without burdening you too much.

0
source share

More articles:


All Articles