Platform-releng/Platform Patch Build BETA JAVA8 Branch

Purpose

This page is a small addition to Platform-releng/Platform_Build and Platform-releng/Platform_Build_Automated. Be sure you have read those first and are familiar with the concepts there.

Notes for BETA_JAVA8 branch

This branch is to (eventually) provide a patch for 4.3.2 Release, that adds support for Java 8, once its released.

Outline of differences and procedures:

The "design" of implementing this has been done to intentionally allow a normal, complete "4.3.2 build", but with the BETA_JAVA8 branches of those projects that have specific changes for Java 8. This type of build can be done in the same way as a normal build, as described in Platform-releng/Platform Build. (But, starting with the BETA_JAVA8 branch of aggregator, naturally). This sort of "complete build" is desired primary as an occasional sanity check ... no plans to deliver a complete rebuild of 4.3.2, such as 4.3.3. (More notes in subsequent section).

P-builds: Patch features for 4.3.2

The primary use of this branch is to rebuild only the dozen or so bundles (from 5 or so repositories) that are involved in the changes for Java 8. This requires setting a few environment variables, and invoking Maven with a specific pom file instead of the default.

Specifically, the key "environment variables" are to to set/export

export BUILD_TYPE=P
export BRANCH=BETA_JAVA8
export PATCH_BUILD=java8patch

Note: for more details, see "mb4P.sh" in the master branch, in the "bootstrap" directory.

The "main pom work" to produce a patch is centered in the java8patch directory of tychobuilder project, so to invoke that specific pom, instead of the default, you need to specify the '-f' parameter to maven.

Plus, there is a special profile, called 'patchBuild' that names the latest 4.3.2 repository to avoid re-compiling things that have not changed.

So all together, the mvn command line, in addition to what ever else you'd normally have, needs to be similar to

 mvn clean verify -f eclipse.platform.releng.tychoeclipsebuilder/java8patch/pom.xml -PpatchBuild

CAUTION: the above procedure is untested and is meant as an outline, so anyone in community that wants to try and build the patch, can at least have these basics documented. If you find errors or improvements, feel free to fix this file (or open a bug in Platform-->Releng.) In production, we use the mb4P.sh file as part of the bootstrap directory in master, which in turn uses a number of bash scripts and ant tasks to do things such as automatically get the latest code from Git, tag the repositories that are built, "add" those latest commits to the aggregator, build summary pages, etc.

Note for "production builds" we (intentionally) still use a 1.7 JRE to "run the build" so if there are bundles use the JavaSE-1.8 BREE (as there is in our BETA_JAVA8 branch), then 1) Tycho 0.20.0-SNAPSHOT must be used (as it is, in our branch) and 2) an appropriate "toolschain.xml" file must be provided that includes a Java 1.8 (Early Access) JRE. For example, in addition to other BREEs and JREs, must have

  <toolchain>
     <type>jdk</type>
     <provides>
         <id>JavaSE-1.8</id>
     </provides>
     <configuration>
        <jdkHome>/shared/common/jdk1.8.0_x64-latest/jre</jdkHome>
     </configuration>
  </toolchain>

Location of build results

The results of our "patch builds" will be left on build machine. This is just to emphasize their temporary nature and maybe be removed without warning.

The build results themselves can be found under

http://build.eclipse.org/eclipse/builds/4P/siteDir/eclipse/downloads/drops4/

Just "drill down" to specific or latest build and you'll see something similar to our normal "download build" page.

A p2 repository (composite) can be found at

http://build.eclipse.org/eclipse/builds/4P/siteDir/updates/4.3-P-builds/

I think at the moment, "auto updates" will not detect changes, and you will have to navigate there with p2 to see if anything is ready to update. It seems it does work, with reduces priority of bug 428087.

Tagging P-builds

Currently, we tag the "build input" for every P-build, similar to how we do I-builds, they have the form "P<date>-".

But, this is only for those repositories that are used for the Feature Patch builds:

eclipse.jdt.core eclipse.jdt.debug eclipse.jdt.ui eclipse.pde.ui

X-Builds: Notes for building Kepler 4.3.2 with BETA_JAVA8 branches

We do have an occasional build of all of Kepler 4.3.2, except with BETA_JAVA8 branches where appropriate.

Currently starting on Monday's 1 PM (Eastern).

The main purpose of these builds is to confirm that nothing "outside" the patches change byte codes ... if they do, they should (likely) be part of the Feature Patch (See bug 428381 for an example.)

X-builds do not push "X-build tags" to repositories (currently ... if ever deemed necessary, please open a releng bug).

We just leave X-builds on the build machine itself, but to find most recent one, you use browser to drill-down following directory:

http://build.eclipse.org/eclipse/builds/4X/siteDir/eclipse/downloads/drops4/

Y-Builds: Notes for building Luna with Java 8 Beta JDT compiler

The JDT compiler we use for our builds is defined by it's "Maven Repo URL" and the exact version we want to use.

So, for example, for normal Luna builds, these are currently defined as follows:

    <cbi-jdt-repo.url>https://repo.eclipse.org/content/repositories/eclipse-staging/</cbi-jdt-repo.url>
    <cbi-jdt-version>3.10.0.v20140120-2305</cbi-jdt-version>

At the moment, during this "beta phase" we do update the JDT compiler in a "local" Maven repository directly on build machine. (This is done to emphasize how impermanent it is, and can change or be deleted at any time, at the request of JDT or Releng team).

But, the "default" values in Luna can be overridden by specifying the Maven properties on the command line. For example, with what ever you normally have on the "mvn clean verify" command line, you could add something similar to:

 mvn clean verify -Dcbi-jdt-repo.url=http://build.eclipse.org/eclipse/jdtx/ -Dcbi-jdt-version=3.9.2.v20140129-2151

But, to repeat, this repo and any specific version can change or be deleted without warning.

We will currently do Y-builds once a week, shortly after our normal I-build -- starting at 1 PM on Tuesday's -- so the "build input" should be (usually) identical to the I-build ... differing only in compiler used.

Y-builds do not push "Y-build tags" to repositories (currently ... if ever deemed necessary, please open a releng bug).

We just leave Y-builds on the build machine itself, but to find most recent one, you use browser to drill-down following directory:

http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/