Platform-releng/Indigo Build Changes

Overview

This document captures work to be performed on the Eclipse project build process during the Indigo development cycle (July 2010 to June 2011). There are three main areas of work. In addition, a fourth area of investigation (Git migration) may start during this development period depending on available resources.

1. Consolidate 3.x and 4.x stream builds
2. Migrate build to eclipse.org hardware
3. Migrate to using Hudson
4. Migration to Git.

Consolidating 3.x and 4.x stream builds

Currently the 4.x stream build repeats much of the same work as the 3.x stream build. Also, many of the bundles in 4.x are still produced by the e4 build process even though the components have graduated/moved into the Platform project. Instead, the 4.x build should consume nothing from e4, and only build the bundles that are actually new or changed in the 4.x stream.

The following steps are needed to get to this point:

• change e4 bundle ownership to new groups as described by the e4->platform move review
• Move forked org.eclipse.ui.workbench bundle into a branch of the real project
• Refactor e4 features to keep dependencies clean
  • Separate graduated parts of CSS and modeled UI into separate features
  • Have org.eclipse.rcp include the relevant CSS and modeled UI features
• Change order of build to (3.7->4.1->e4 instead of (3.7->e4->4.1)
  • Fetch graduated e4 bundles as source rather than binary in 4.1 build
  • Fetch graduated e4 bundles as binary from the 4.1 repository in the e4 build

• Signing of 4.1 builds
  • Short form of 4.1 build currently doesn't sign
  • Find a custom target somewhere in the 4.x build to perform signing of the right contents. After compile (post build).
  • Andrew to investigate and come up with a recommendation

• e4 bundle/package rename...
  • Currently e4 bundles that graduated to platform still have "org.eclipse.e4..." in the name. They should be renamed to org.eclipse.platform... or something similar.
  • In some cases simply dropping "e4" from the bundle/package names would create ambiguity/collision with legacy 3.x bundle/package names. Likely want some way to keep the "old" and "new" bundles separate
  • Once new names are decided, move graduated bundle into new home under /cvsroot/eclipse with their new name.

• Running all Eclipse SDK tests
  • Currently 4.1 build does not run any tests
  • Need to fork tests that are affected by 4.x changes
  • Strictly speaking only need to run platform tests, but running JDT/PDE tests could also be helpful in picking up platform regressions in 4.x stream (or incorrect assumptions in JDT/PDE about platform behaviour or API)

• Fork platform doc (ISV and user)
  • Once 4.1 stream has distinct documentation, will need to fork the two documentation bundles
  • Update screen shots, etc, in 4.1 doc
  • Add new 4.1 API to the javadoc in the 4.1 doc

Moving to Hudson

• Currently have a permission problem, hudson build cannot promote builds to download directory. Most projects using hudson keep "build" and "promotion" as separate steps
• need separate cron job to promote build afterwards (potentially chained to build so that it promotes automatically
• Currently platform build not factored to handle this (i.e., make promotion a distinct step)

Moving to eclipse.org hardware

• Setting up windows tests - need to figure out how to spawn windows tests (virtualize or not?)
• Mac OS missing - IBM donation unlikely but perhaps another company will step forward
• performance tests hard on eclipse.org because virtualized test machine is not stable enough. Will likely need to continue running performance tests on IBM hardware. This is not too bad because it is only on three builds per week and not running with every build.

Move to GIT

• Blocked by lack of a Git fetch factory for PDE
• Need to bundle eGit and feature factory in base builder
• Potential problem bundling eGit in base builder if eGit is not graduated
• Can we just move some bundles to GIT or does the entire project have to move?
  • Candidate deeplink feature in e4 project as a guinea pig