Hi guys!
Today I would like to share my experience on how to survive the situation when you are developing under Eclipse and have a LOT of plugins. For example, in my current project we have more than 1000 plugins. We use “Build Automatically” Eclipse feature and if the workspace is not configured well, sometimes you have to wait a half of an hour just for importing a new class.
Fortunately, there are several tricks that could significantly speed up the development process. The most important one is Target Platform Eclipse feature.
Target Platform
Target Platform is just a set of plugins which your workspace will be built and run against. These plugins are not shown in the plugin tree and do not participate in the automatic build process. And it makes all the difference!
As the default Target Platform Eclipse uses all plugins located in the eclipse folder. If your product has a big part that is rarely changed like “core” functionality, it is worth to build the core plugins separately and add them to the Target Platform. In our case it reduces build time from 30 minutes to several tens of seconds (a hundred times faster).
Default Eclipse Target Platform
Core plugins moved into the Target Platform
1338 plugins in an Eclipse workspace
106 packages after using SDK
Target Definitions
Eclipse allows to have several pre-configured Target Platforms and to switch between them. Such configurations are named Target Definitions. The active Target Definition is the Target Platform.
Target Definitions are very useful when you have several different sets of plugins for different environments like x32 and x64. Look at a screen shot how Target Platforms look like in the PIM project when the core plugins are under development:
Managing Target Definitions
It is possible to save a Target Definition as a file and include into a project. It is allowed to have as many Target Definition files as necessary. Then, when a new workspace is created, the project could be imported together with the saved pre-configured Target Definitions.
Plugins in a Feature
Features
Another great thing for structuring workspace and keeping run configurations in shape is Features. A Feature is used to package a group of plug-ins together into a single unit. Then it is much easier to manage, for example, 5 features instead of 100 plugins.
Take a look at a typical feature configuration. It consists of many plugins. When configuration is finished, the feature could be used as a single unit.
I saw an Eclipse project containing about 1000 plugins that did not use features. It was a nightmare for developers to manually set up hundreds of plugin dependencies just to run the application.
Plugins in debug configuration
Features in debug configuration
Take a look at our PIM Server debug configuration. Note, there are just several pre-configured features selected.
Then take a look at the same configuration that consists just of plugins without features. Note, there 220 plugins instead of just 7 features.
Remember the Target Platform is the constant part of the debug configuration, so it is not necessary to include it explicitly.
If your project consists of several hundreds of plugins, try to configure the Target Platform and use Features. Maybe you will love Eclipse after this. 😉
Bye!
