EclipseLink Build

1. EclipseLink Build Eric Gwin

2. Eclipse Terminology Features P2 Current Process Architecture Environment Build types Customization Challenges/Issues Number of Branches Build times/Hardware Foundation assumptions Future Build migration? Repository migration? Test Build Rework Discussion Overview

3. Terminology - Features The Eclipse Install exposes projects as ‘features’. Basically, a feature is a jarred xml document that describes a logical collection of project bundles and dependency bundles necessary to be able to perform a specific set of functionality. EclipseLink is organized into the following features: • org.eclipse.persistence.jpa • org.eclipse.persistence.jpa.source • org.eclipse.persistence.moxy • org.eclipse.persistence.moxy.source • org.eclipse.persistence.sdo • org.eclipse.persistence.sdo.source • org.eclipse.persistence.sdk

4. Terminology – Provisioning Platform (P2) Artifacts are the actual content being installed or managed. Bundle JARs and executable files are examples of artifacts. Artifact Repositories hold artifacts Installable Units are metadata that describe things that can be installed. They are not the things themselves. So an IU for a bundle is not the bundle but a description of the bundle: its name, version, capabilities, requirements, etc.. The bundle JAR is an artifact. Metadata Repositories holds installable units (IU). Eclipse P2 repositories are typically organized into a ‘feature’ dir holding the feature jar files (IU artifacts), and a ‘plugins’ dir holding the bundles (artifacts) with the actual repositories stored as jarred xml files at the same level. Categorization consists of metadata that groups IUs together

5. Build Process - Architecture Why ANT? • Ease of migration (Historic) • Flexibility Architecture Overview • Bootstrap – env setup • Autobuild – build flow/process • Trunk build – artifact generation Execution Control • crontab

6. Build Process - Environment Multi-platform • JDK 6 • Junit 4.5 Constraints • Published builds must be generated on Foundation Hardware • PPC64 Box • Backward compatible to JVM 5 Execution environment

7. Build Process - Build types Continuous Build • Test recent transactions • Must complete within 15-20 min Build Bundles & tests, run SRG Nightly Build • Nightly integration of transactions • More thorough Testing • Must complete by 6am ET Build bundles & tests, submit for signing, run LRG, build distribution artifacts, publish distributions to web, push to Maven, generate P2 repository

8. Build Process - Build types (cont.) Oracle Submission process • Included for consistency • Runs on Oracle Hardware • Artifacts contributed to SVN Test for build need, build bundles, check-in artifacts Milestone Promotion • Flag a build as a development milestone (not a build) • Build numbering does not change (X.X.X.qualifier) • Can have same build available as nightly, RC, and release • ‘release’ is a special milestone Grabs specified build from nightly area, repackages to use signed artifacts, publish distributions to web, push to Maven, generate P2 repository

9. Build Process - Customization Changing Defaults • ${user.home}/build.properties – will allow override of any variable • ${user.home}/test.properties & ${test.properties} Bundle Generation • Dynamic searches • Bnd – default jarname, searches ‘buildsystem’ and ${extensions.depend.dir}: if not found Error • org.eclipse.osgi – default jarname, searches in ‘jpa/plugins’, ‘/plugins’, and ${extensions.depend.dir}: if not found skips weaving and equinox extension builds • ${oracle.extensions.depend.dir} if not found oracle extension build is skipped

10. Build Challenges Number of Branches • Three (3) is effective maximum • Have 3 test db logins • 20 min CB window • Currently running with four (4) • Alternating days for 1.2/1.1.4 builds • No CB for 1.2 Build times/Hardware • As Simultaneous Release Date approaches build server load increases, also increasing build times and test failures due to resource availability. • Moving CB to Oracle may help, but is less visible. • New Build methodology may help, but means sacrificing build flexibility

11. Build Challenges (Cont.) Foundation assumptions • Most Foundation processes (signing, P2 generation, etc) assume PDE, or at least ‘headless’ execution of eclipse. Since our builds are driven by Ant it means many process must be reverse engineered and re-engineered for our use. • Migrating build process will help, but it means tying our builds to the Eclipse platform. • ‘Runtime’ contributions are not yet generally understood.

12. Looking to the future Build migration • Several Build alternatives can be explored to alleviate challenges • Using Hudson to drive builds may allow for parallel processing • Migrating to Buckminster may remove the need to reengineer certain processes. • Ant 1.8 available • Adoption will require build rework of most ‘test’ projects Repository migration • Migration to Git? Eclipse appears to be concentrating on migrating CVS projects currently, but have heard discussion about de-supporting SVN eventually. Test Build Rework • Rework of testing to not build before test execution on hold. Need to rework most testing processes, or wait until fewer branches active to ease transition.

13. Discussion Questions?