Distributed release engineering @ eclipse.org – a field report
We, the Jubula project team members, recently open sourced main parts of the commercial UI testing tool GUIdancer and participated with our newly created Eclipse project in the Eclipse Indigo release train.
Joining the train required a lot of effort to meet the versatile internal and external artifact requirements. We start by looking at the specific needs we had:
- Open your source: a pre-requisite for an external build process to take place is the external presence of the sources to build in combination with the absence of non-EPL conform code and artifacts (JARs).
- Build at Eclipse: in order to “produce” artifacts as an Eclipse project these artifacts have to have a certain shape and fingerprint: signed plug-ins, fragments and features bundled as an independently available update site.
- Keep on building independently: apart from the external build and release engineering process we, as a company, still wanted to be able to “build-on-our-own”.
Based on these requirements, we describe the resulting build infrastructure at eclipse.org – in our case a combination of Hudson, Tycho & Maven, ANT, git and the way we tied our internal company builds and releng workflows to these artifacts.
As a conclusion, we look at the experiences we gained while becoming an open source project with regard to release engineering and build environment requirements. We look at obstacles we encountered and give advice on how to cope with them in general.