>I wrote a while ago about how eclipse shouldn’t need eclipse to build eclipse, and said I’d report back findings here. Well, I took the easy piece first, which is packaging. Packaging in this case is just combining various plugins into a customized version of eclipse. To help with this, I’ve used a product for a while called Custom Eclipse Builder. It’s an ANT build script and a set of property files that will automate the packaging of a customized version of eclipse. You may control what plugins get incorporated and download them from multiple sources. The key is that they be available as an archive version.
The features I need in a custom eclipse installation are:
- Eclipse Platform.
- Eclipse CVS Plugin
- Subversion support (I happen to use Subclipse)
- XML Modeling support via Hypermodel by Dave Carlson
- Mylyn Mantins Connector
- Topcased UML
- Web Standard Tools
- Secure FTP via JCraft SFTP plugin.
- Data Tools Platform.
- EMF, UML, and other required modeling libraries and plugins.
- X-Assist XSLT (now part of the XSL Tooling Incubator project)
I need versions to run on Windows, Linux, and Mac.
Doing this all manually can be a time consuming process. So I’d rather have it automated. A complete build that includes all three platforms takes between 10 and 20 minutes depending on download connection speed, and how many files are stored locally as compared to fetched from the Internet.
I setup the builds to be triggered by our build system, Luntbuild. I happen to like Luntbuild over Cruise Control because it helps separate the build process from the check out process. I can write one build file that works on multiple workspaces or locations with out worrying about how the files are going to be checked out. It also sends out notifications through multiple channels.
As for doing plugin builds, I’ll be experimenting over the next week with the Ant4Eclipse project’s builds to build individual plugins. The keys to a good build are that it meets the following requirements:
- It has to be able to run on any machine. In my case I need the same build to run on Linux as well as Windows. This requires some thought ahead of time, but it makes it much easier when working in a multi-developer/multi-platform environment.
- Be repeatable.
- Be easily maintainable by others.
- Easy to setup and execute.
- Support automate reporting (this can be done in the build or through the build system that manages the builds).
Most eclipse builds I’ve seen have been setup to be very platform specific (i.e. a build is usually targeted to run on a particular platform like Linux or Windows, but is difficult to get running on both). They also fail the above requirements. A build should be able to be executed out of the box regardless of what system it was originally written to run on. If a user has all necessary source and supporting libraries, it should be an execute and go configuration.
Packaging is the easy part, the more complicated part is to be tackled next. Building plugins with out a headless eclipse environment. That is where I hope Ant4Eclipse comes to the rescue. Results from that experiment will be another topic.