Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Build Retrospective: EMF, UML2, EMFT, GEF

EMF / UML2 Build

EMF and UML2 run separate builds, but share much of the same infrastructure. All code is public in CVS, though is currently undergoing restructuring to make it easier to find & use.

A few basic characteristics of these builds are:

  • Use PDE running in headless Eclipse on Linux (Debian, GTK, 2.4.25 kernel, 32-bit), but include an out of date version.
  • Updates to base builder only when required due to breakages in org.eclipse.releng.basebuilder or to support new function in Eclipse or basebuilder.
  • No EMF performance data after 2.1 release (last year). No performance data for UML2.
  • Customizations and automations not in PDE written in a mix of shell, ant (script + custom tasks), or plain java
  • UI tests are NOT supported on current build server
  • Source plugins/features bundled as src.zips in .source plugins in SDK
  • Custom doc. plugin builder (not PDE generated)

Running a build

Builds can be run in three ways:

  • On demand (with web UI or shell script)
  • Scheduled (nightly crons)
  • RSS response (update to a feed causes a new build using that new driver)

Build results

A successful build includes the following artefacts:

  1. 7 EMF zips, 4 UML2 zips
  2. mapfiles, config files
  3. tests + results (PDE)
  4. plugin ranges in MANIFEST.MF files set dynamically, except where already defined statically; UML2 ranges all set statically
  5. .qualifiers for all plugins/features

Publishing a build

Publishing a build (promoting bits from our build server to can be run in two ways:

  • On demand (with web UI or shell script)
  • Scheduled (nightly crons)

Additionally, there is a script available to rename builds and their artefacts so that when Eclipse renames an RC build to its final GM, the same can be done here without the need to respin. This includes updating links in build pages, logs, and config files to point to the renamed upstream dependencies.

Published artefacts

A successful promote generates the following artefacts:

  1. Zips/MD5s (verify scp completeness, set correct group permissions)
  2. RSS feed update
  3. Map file update
  4. Release notes generation/merge (using CVS and Bugzilla data)
  5. New build announced on website
  6. Assigned Bugzillas automatically move to Fixed state
  7. Fix cross-project javadoc links (eg., between EMF and Eclipse or XSD and EMF) and scp to website
  8. Update Manager site+jars generation/merge (verify scp completeness)
  9. Maven2 jar generation (EMF only, to Apache Tuscany project)
  10. New build announced in newgroup (with optional message nesting)
  11. Optional email notification

EMFT Build

Based on the EMF/UML2 build, but simplified and streamlined, the Eclipse Modeling Framework Technologies build needs to support not 1 or 2 projects' variations, but as of this edit, 10 subprojects, each with its own characteristics, differences, plugin/feature sturcture, dependencies, and deviations from any perceived baseline.

Variations include:

  • Multiple namespaces (org.eclipse.emf.transaction, org.eclipse.emf.workspace)
  • Builds requiring JDK 5.0 vs. 1.4
  • Builds requiring -enableassertions
  • Suppression of compiler warnings
  • Examples bundled in SDK vs. Examples NOT in SDK
  • Up to 4 upstream dependencies
  • 3rd party jars in CVS (but not published in zips)
  • 3rd party jars local to filesystem (copied into build and removed before packaging into zips)
  • Tests that depend on Examples
  • ... and more!

Build and promotion artefacts are the same as those above except:

  • All projects have only 4 zips - SDK, Runtime, Examples, Automated Tests
  • No dynamic assignment of MANIFEST.MF plugin ranges
  • No RSS feed (yet)
  • Assigned Bugzillas do not yet automatically move to Fixed state
  • No Maven2 jars
  • Build server is in most cases the same as above, but for projects whose contributors are external to IBM, an eclipse virtual server,, is used.
  • Where UI tests are required, they are currently run offline on developer's workstations before promoting builds.

For more details on this build, see:

GEF Build

The GEF build is currently on hold pending plans to commit new code. It was last used by Tom McDougall in June 2006 for GEF 3.2's release. The build is based on PDE, and includes the following components:

  • Runs in VMWare Linux session
  • Produces performance data for both Linux and WinXP
  • Includes UI tests in its JUnit test suite
  • Most code is in CVS but bootstrap and setup code is NOT yet available
  • No online Javadoc, release notes, RSS feeds
  • No bugzilla/cvs or email/newsgroup automation

Back to the top