Our Thinking

Multiple Eclipse Configurations

Posted by Duane Colley on Sep 3, 2013 10:23:47 AM

If you are like me and have embraced Eclipse as your preferred IDE for dabbling in various java related frameworks, you have undoubtedly run into a situation where Eclipse is no longer happy. Either from slowing to a crawl, or the Scala plugin is complaining while you are trying to do Android development or one of many other possibilities. Besides, why do you want the overhead of the Android plugin when you are working in Scala, or the svn headaches when you are using git?

The simplest solution is to install plugins in separate configurations and leave the base setup for plugins that are going to be common across all your dabbling.

Two important Eclipse command-line switches come into play here:

  • -configuration (which configuration to use)
  • -data (which workspace to use)

The following examples will be setting up the configurations underneath the eclipse install in a “configs” directory, e.g. eclipse/configs/android/configuration.

A complex batch script that contains all configurations setups, something from the old college days when they taught .bat programming.

run-eclipse.cmd scala-segue-server

This could lead to the undesirable side effect of possibly self-documenting your environment setup, reminding you what is what and make it easy to transition to another computer – can’t have that, so we’ll move on.

A simple batch file/shell script to launch Eclipse with a specific configuration and workspace, for example:

run-eclipse.cmd scala D:\usr\local\workspaces\workspace-scala

Where the run-eclipse.cmd is nothing more than:

D:\usr\local\eclipse-installs\eclipse\eclipse.exe -clean -configuration configs/%1/configuration -data %2

  • Replace with eclipse.exe or eclipsec.exe as you see fit.
  • -clean is optional.
  • In this case, eclipse will setup a configuration in eclipse/configs/scala/configuration.
  • And the workspace will be in D:\usr\local\workspaces\workspace-scala.

Personally, I’ll forget about the batch file when I transition to a different machine, so I’ll keep things simple by making up windows shortcuts. As I always use a different workspace, either by project, client and/or technology, I also include the workspace in the launch parameters.

Examples:

D:\usr\local\eclipse-installs\eclipse\eclipse.exe -clean -configuration configs/android/configuration -data D:\usr\local\workspaces\workspace-mobile

D:\usr\local\eclipse-installs\eclipse\eclipse.exe -clean -configuration configs/scala/configuration -data D:\usr\local\workspaces\workspace-scala

I also have a shortcut to the base install for “stuff” and installing common plugins.

D:\usr\local\eclipse-installs\eclipse\eclipse.exe, usually to the default workstation for simple things that just use the functionality of the core J2EE project.

Some additional options to consider:

  • Having the configs directory not under the Eclipse install, this could theoretically make moving to the newer version of Eclipse easier.
  • Adding additional memory and other command-line options on the shortcut/batch file instead of in the eclipse.ini.
  • Setting up your eclipse install structure to match the various versions of Eclipse you are using by project.

Conclusion

Using multiple configurations and workspaces should keep Eclipse performance optimal for your project specific needs by keeping overhead low and not requiring multiple installs of Eclipse.

Topics: Languages, Tools

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates