*Oracle 1.6 JDK needs to be on PATH (OpenJDK also works and is becoming officially supported on Red Hat Enterprise Linux for Kepler. See [http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_3.xml#target_environments plan]).

+

*Oracle 1.8 JDK needs to be on PATH as the VM that "runs the build". (OpenJDK also works and is becoming officially supported on Red Hat Enterprise Linux for Kepler. See [http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_3.xml#target_environments plan]).

*Verify correct version of java is used

*Verify correct version of java is used

*Set JAVA_HOME to point to your JDK

*Set JAVA_HOME to point to your JDK

*Ensure your java is set to run in Server mode

*Ensure your java is set to run in Server mode

−

Some of the inner build callouts, like the SWT fragment build, depend on having an Oracle JVM.

+

* Notes:

−

+

:* For some uses, lower VM levels might work, but it's recommended to use Java 8, to avoid issues in some areas, such as JavaDoc generation, or reading pack.gz files.

−

(Seems that currently all JDKs from 1.4 to 7 with a configured toolchains.xml are needed to get a successful build. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=409790#c32 Bug report]&nbsp;and [http://dev.eclipse.org/mhonarc/lists/cbi-dev/msg01025.html Mailing List])

+

:* Some of the inner build callouts, like the SWT fragment build, depend on having an Oracle JVM.

+

:* Not sure is this is still required, if using Java 8 to run the build, but highly recommended (if not required) to have all JDKs, from CDC-1.0/Foundation-1.0 to Java 8, in a configured toolchains.xml file. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=409790#c32 Bug report]&nbsp;and [http://dev.eclipse.org/mhonarc/lists/cbi-dev/msg01025.html Mailing List]) and see the Section below titled 'Using BREE Libs'.

<br>

<br>

Line 24:

Line 25:

A parameter used by the build "-XX:-UseLoopPredicate" is not recognized by java when running in Client mode. To check which mode you are running in by default run:

A parameter used by the build "-XX:-UseLoopPredicate" is not recognized by java when running in Client mode. To check which mode you are running in by default run:

−

$ java -version

+

$ java -version

−

java version "1.7.0_09"

+

java version "1.8.0_60"

−

Java(TM) SE Runtime Environment (build 1.7.0_09-b05)

+

Java(TM) SE Runtime Environment (build 1.8.0_60-b27)

−

Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

+

Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

−

If the last line says "Client VM" instead of "Server VM" then you are running in client mode. In which case you will need to modify the file '''/jdk1.7.0_09/jre/lib/amd64/jvm.cfg''' and ensure that the line '''-server KNOWN''' is the first line in the file.

+

If the last line says "Client VM" instead of "Server VM" then you are running in client mode. In which case you will need to modify the file '''/jdk1.8.0/jre/lib/amd64/jvm.cfg''' and ensure that the line '''-server KNOWN''' is the first line in the file.

−

=== Maven 3.0.4 ===

+

=== Maven 3.1.1 ===

*Download from http://maven.apache.org/download.html or use your Linux distribution provided version (whether it works depends on the distribution).

*Download from http://maven.apache.org/download.html or use your Linux distribution provided version (whether it works depends on the distribution).

Line 152:

Line 153:

git checkout -b master origin/master

git checkout -b master origin/master

−

=== Check for Necessary pom.xml updates ===

+

=== Check for necessary pom.xml updates ===

−

From time to time committers will forget to update the bundle version contained in a pom.xml when a bundle version change is made in a bundle project manifest. If building from master you should likely check the latest I-Build from the eclipse project [http://download.eclipse.org/eclipse/downloads/ downloads page] for a link called '''''POM updates made''''' to see if there are any outstanding patches that you should apply before allowing a successful local build.

+

From time to time committers will forget to update the bundle version contained in a pom.xml when a bundle version change is made in a bundle project manifest. If building from master you should likely check the latest I-Build from the eclipse project [http://download.eclipse.org/eclipse/downloads/ downloads page] for a link called '''''POM updates made''''' to see if there are any outstanding patches that you should apply before allowing a successful local build.

=== Running the build ===

=== Running the build ===

Line 162:

Line 163:

mvn clean verify

mvn clean verify

−

<br> '''NOTE:''' If you build multiple streams on the same system, you'll want to add ''-Dmaven.repo.local=/some/directory/somewhere'' to the end of the 3 mvn commands to avoid collisions (Using a different local repo for each stream). Most casual developers won't be affected.

+

:'''NOTE:''' If you build multiple streams on the same system, you'll want to add ''-Dmaven.repo.local=/some/directory/somewhere'' to the end of the 3 mvn commands to avoid collisions (Using a different local repo for each stream). Most casual developers won't be affected.

−

*On Windows use ''-Dmaven.repo.local=C:\path\to\somewhere''

+

::*On Windows use ''-Dmaven.repo.local=C:\path\to\somewhere''

+

+

==== Running the build on R4_3_1 tag ====

+

+

:'''NOTE for building from R4_3_1 tag:''' Due to some mis-timing of removing a temporary repository ({{bug|418627}}) if you want to re-build Eclipse 4.3.1 from its tag, you will need to add following '-D' option for the current license repository. This is not required if building from master branch or current R4_3_maintenance branch.

If you use Java 8 to "run the build", you can disregard this section. If you use Java 7, there is a system variable that has to be specified, to correctly generate JavaDoc for the org.eclipse.jdt.doc.isv bundle. The reason is that there is one bundle (with API) that depends on Java 8, namely org.eclipse.jdt.annotation, version 2.x.x. To correctly generate that JavaDoc, you just provide a system variable called "eclipse.javadoc" that points to the 'javadoc' executable from a Java 8 installation. For example:

+

+

-Declipse.javadoc=/shared/common/jdk1.8.0_x64-latest/bin/javadoc"

+

+

If specified, the ant tasked used to build the Java Doc will use that executable. Otherwise, it will use the Java Doc tool that is associated with the currently running Java.

+

+

=== Running the build without tests ===

+

+

From the aggregator root, run:

+

+

mvn clean verify -DskipTests=true

+

+

:'''NOTE''' "-Dmaven.test.skip=true" cannot be used in CBI, see {{bug|456510}}

=== Build result ===

=== Build result ===

Line 244:

Line 267:

mvn clean verify \

mvn clean verify \

−

-Dmaven.test.skip=true -Dnative=gtk.linux.x86_64

+

-DskipTests=true -Dnative=gtk.linux.x86_64

−

== running the tests ==

+

=== Building Selected Projects ===

−

Copy the junit tests and the CBI SDK (pick the one for your platform) that was built to a testing directory. Also unzip the junit tests.

+

Instead of a full build, selected projects can be built by going to the desired root directory of the project(s) and specifying the <pre>build-individual-bundles</pre> profile.

+

+

Example:

+

+

(from the eclipse.platform.releng.aggregator repository root) \

+

cd rt.equinox.framework \

+

mvn -Pbuild-individual-bundles clean verify

+

+

This would build all projects under rt.equinox.framework.

+

+

Example:

+

+

(from the eclipse.platform.releng.aggregator repository root) \

+

cd rt.equinox.framework/bundles/org.eclipse.osgi \

+

mvn -Pbuild-individual-bundles clean verify

+

+

This would build only the org.eclipse.osgi project.

+

+

== Build output: p2 repo and RCP products ==

+

+

Once build is complete, look in the following folders for the usual output artifacts:

+

* <tt>eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products</tt> for the archives of the Eclipse SDK. (Siblings of <tt>sdk</tt> folder contain other RCP products produced by Platform Build). Those are the packages that are typically published at http://download.eclipse.org/eclipse/downloads/drops4/ .

+

* <tt>eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/target/repository</tt> for the typical p2 repository containing installable unit shipped by Platform Build. This is the repository that get typically added to http://download.eclipse.org/eclipse/updates/ .

+

+

== Running the Eclipse platform tests ==

+

+

Copy the junit tests and the CBI SDK (pick the one for your platform) that was built to a testing directory. Also unzip the junit tests and enter them.

mkdir -p /var/tmp/lts/R3_platform-tests

mkdir -p /var/tmp/lts/R3_platform-tests

Line 255:

Line 304:

cd /var/tmp/lts/R3_platform-tests

cd /var/tmp/lts/R3_platform-tests

unzip eclipse-junit-tests-bundle.zip

unzip eclipse-junit-tests-bundle.zip

+

cd eclipse-testing

Modify the file equinoxp2tests.properties to point to the CBI built repository. (This example uses /home/user/R3_platform-aggregator as the CBI platform root)

Modify the file equinoxp2tests.properties to point to the CBI built repository. (This example uses /home/user/R3_platform-aggregator as the CBI platform root)

Line 266:

Line 316:

Rename your org.eclipse.sdk.ide-linux.gtk.x86_64.tar.gz you copied earlier to match the name you jotted down.

Rename your org.eclipse.sdk.ide-linux.gtk.x86_64.tar.gz you copied earlier to match the name you jotted down.

Prerequisites

Free HDD space

Oracle Java 1.8

Oracle 1.8 JDK needs to be on PATH as the VM that "runs the build". (OpenJDK also works and is becoming officially supported on Red Hat Enterprise Linux for Kepler. See plan).

Verify correct version of java is used

Set JAVA_HOME to point to your JDK

Ensure your java is set to run in Server mode

Notes:

For some uses, lower VM levels might work, but it's recommended to use Java 8, to avoid issues in some areas, such as JavaDoc generation, or reading pack.gz files.

Some of the inner build callouts, like the SWT fragment build, depend on having an Oracle JVM.

Not sure is this is still required, if using Java 8 to run the build, but highly recommended (if not required) to have all JDKs, from CDC-1.0/Foundation-1.0 to Java 8, in a configured toolchains.xml file. See Bug report and Mailing List) and see the Section below titled 'Using BREE Libs'.

Java Server Mode

A parameter used by the build "-XX:-UseLoopPredicate" is not recognized by java when running in Client mode. To check which mode you are running in by default run:

If the last line says "Client VM" instead of "Server VM" then you are running in client mode. In which case you will need to modify the file /jdk1.8.0/jre/lib/amd64/jvm.cfg and ensure that the line -server KNOWN is the first line in the file.

Note: The final "z" parameter at the end of the command is important as tells git to checkout the repository and rename it to "z". This reduces the path length of the repository to be short enough to workaround Bug 376400.

If you want to switch from another branch to this one, replace git merge origin/master with:

git checkout -b master origin/master

Check for necessary pom.xml updates

From time to time committers will forget to update the bundle version contained in a pom.xml when a bundle version change is made in a bundle project manifest. If building from master you should likely check the latest I-Build from the eclipse project downloads page for a link called POM updates made to see if there are any outstanding patches that you should apply before allowing a successful local build.

Running the build

From the aggregator root, run:

mvn clean verify

NOTE: If you build multiple streams on the same system, you'll want to add -Dmaven.repo.local=/some/directory/somewhere to the end of the 3 mvn commands to avoid collisions (Using a different local repo for each stream). Most casual developers won't be affected.

On Windows use -Dmaven.repo.local=C:\path\to\somewhere

Running the build on R4_3_1 tag

NOTE for building from R4_3_1 tag: Due to some mis-timing of removing a temporary repository (bug 418627) if you want to re-build Eclipse 4.3.1 from its tag, you will need to add following '-D' option for the current license repository. This is not required if building from master branch or current R4_3_maintenance branch.

Running the build on master (or R4_4_maintenance) using 1.7 JRE

If you use Java 8 to "run the build", you can disregard this section. If you use Java 7, there is a system variable that has to be specified, to correctly generate JavaDoc for the org.eclipse.jdt.doc.isv bundle. The reason is that there is one bundle (with API) that depends on Java 8, namely org.eclipse.jdt.annotation, version 2.x.x. To correctly generate that JavaDoc, you just provide a system variable called "eclipse.javadoc" that points to the 'javadoc' executable from a Java 8 installation. For example:

-Declipse.javadoc=/shared/common/jdk1.8.0_x64-latest/bin/javadoc"

If specified, the ant tasked used to build the Java Doc will use that executable. Otherwise, it will use the Java Doc tool that is associated with the currently running Java.

The reason is that /targets is specified in the .gitignore file, so git ... ignores them. They are included in .gitignore so they are not accidentally committed and don't clutter visual displays of "changes". Normally Maven will clean those up before a build, but in case you want to be positive you do not get an "old" copy, of one of the target artifacts, use -x.

Using BREE Libs

BREE libs can be used to build using the same BREE as what is used on build.eclipse.org. You will first need to download and install the ee.zip attached to Bug 386649 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=386649) and follow the instructions in the description of the bug.

Here's an example of toolchains.xml. It currently only works with Oracle JREs (see bug 389856). Someone running the platform build would need their own version of toolchains.xml in their build ids home directory's .m2 directory (~/.m2/toolchains.xml) which points to the location on their file system of the tools required (BREE libs and JDKs).

Once setup you can inform the build to use it by passing -Pbree-libs on the mvn build command.

Pack200 & Signing

Pack200 & Signing is supported when built using build.eclipse.org and is disabled by default.

Simply Run the build with -Peclipse-sign parameter.

Advanced

If you'd like to build your own version of the eclipse-jarsigner-plugin you can use the instructions below.

Build output: p2 repo and RCP products

Once build is complete, look in the following folders for the usual output artifacts:

eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products for the archives of the Eclipse SDK. (Siblings of sdk folder contain other RCP products produced by Platform Build). Those are the packages that are typically published at http://download.eclipse.org/eclipse/downloads/drops4/ .

eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/target/repository for the typical p2 repository containing installable unit shipped by Platform Build. This is the repository that get typically added to http://download.eclipse.org/eclipse/updates/ .

Running the Eclipse platform tests

Copy the junit tests and the CBI SDK (pick the one for your platform) that was built to a testing directory. Also unzip the junit tests and enter them.

Apple JVM renamed rt.jar to classes.jar causing the CBI Platform build to fail when building on macosx. Running the build a 2nd time after the failure however produces a working build. It isn't ideal to have the user run the build twice though.

A workaround for this issue is to create a symbolic link for classes.jar to rt.jar.

In PDE build the features specify what plugins to build and the map files specify where to get the plugin projects and which version to check out.

In the CBI build the pom.xml files and the directory structure specify what plugins to build and the aggregator git repo specifies which checkout is the build input by capturing the commit for each component repo as a submodule entry.

The manual process for submitting Platform UI for a build involves updating the submodule in the aggregator: