Eclipse 3.2 M5 will introduce a new extension point and new API for supporting other repositories during a headless build. The contributed patch grow out of my modifications to get PDE Build running with ClearCase.

Hopefully, the copy extension will also appear in 3.2 M6. This is a very simple extension but it should enable PDE Build to support any repository out of the box. It fetches features, plug-ins and fragments from any accessible disc location. We’ve been using this extension in our ClearCase & CruiseControl environment since 2002.

Our automated build process is as follows. We use CruiseControl as the leading system. It triggers rolling compiles every 30 minutes if any check-ins occurred, nightly builds every weekday (regardless of modifications), maintenance builds every Thursday (if the branch was modified) and integration, stable and release builds upon request. The triggered script takes some arguments (e.g. build type, label, date & time, etc.), bootstraps the PDE Build environment and invokes PDE Build with these arguments.

The bootstrapping process updates a ClearCase view containing the PDE Build environment and copies the org.eclipse.releng.basebuilder together with our product builder to a temporary build location outside the ClearCase view. It then invokes PDE Build.

PDE Build starts with configuring a ClearCase view with the correct ConfigSpec (depending on the build type). The map files are fetched from this view and point to the VOB location of all features, plug-ins and elements required for our product. There exists also a build configuration file (like a build.properties), which points to the required base components (e.g. Eclipse Platform, GEF, JDT, etc.). This file is fetched together with the map files and allows maintaining all release-specific information (except the ConfigSpec ) inside ClearCase.

The copy extension supports a really simple map file format. It contains only three arguments separated by the comma char (“,”).

plugin@com.my.plugin=COPY,/build_view/vobs/,eclipse_vob/plugins/com.my.plugin

The first argument is a pointer for PDE Build that the copy extension has to be used for fetching the element. The second and the third argument describe the source location where the element must be copied from. The generated fetch scripts will fetch my plug-in from /build_view/vobs/eclipse_vob/plugins/com.my.plugin. But this would not work on Windows because is path would not point to a valid path location on a Windows build machine.

To overcome this issue the path is split into two arguments. This allows customizing the path at build time. The first part can be overwritten with the fetchTag property. For example, this allows pointing to two different ClearCase views or running the same build environment on different systems (e.g. Linux and Windows). On a Windows build machine one can set fetchTag=COPY=X:/ in the build.properties file. The generated fetch scripts would then fetch my plug-in from X:\eclipse_vob\plugins\com.my.plugin. There is no need to have different map files for Windows or Linux. .