Builds

The central EGit and JGit builds run on the Jenkins build infrastructure provided by the Eclipse foundation.

Prerequisites for the Maven build are

JGit

EGit

Mailing Lists

If you're interested in following builds, please check out the following mailing lists:

Maven Build

To build JGit or EGit versions <= 5.12.0 maven must be run using Java 1.8. Ensure that environment variable JAVA_HOME points to a Java 1.8 installation.

EGit versions >= 5.12.1 and < 6.0.0 can be built with any Java >= 1.8, but the build uses maven toolchain definitions. To run a local EGit build for these versions (including the 'master' branch, i.e. EGit nightly), you need to have a local file ~/.m2/toolchains.xml providing at least a JDK toolchain definition for "JavaSE-1.8":

<?xml version="1.0" encoding="UTF8"?>
<toolchains>
   <toolchain>
      <type>jdk</type>
      <provides>
         <id>JavaSE-1.8</id>
         <version>1.8</version>
      </provides>
      <configuration>
         <jdkHome>/absolute/path/to/jdk1.8</jdkHome>
      </configuration>
   </toolchain>
   <toolchain>
      <type>jdk</type>
      <provides>
         <id>JavaSE-11</id>
         <version>11</version>
      </provides>
      <configuration>
         <jdkHome>/absolute/path/to/jdk11</jdkHome>
      </configuration>
   </toolchain>
</toolchains>

The jdkHome directory is the one that contains the bin directory in which there is the java executable.

Also include a definition for a Java 11 toolchain as shown above: EGit versions >= 6.0.0 require at least Java 11 to build, and require a Java 11 toolchain definition for running the tests.

Building JGit versions < 6.0.0 with maven requires running maven with Java 1.8 in all cases.

Building JGit versions >= 6.0.0 with maven requires running maven and compiling with at least Java 11.

Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):

[~/src/jgit] $ mvn clean install
[INFO] Scanning for projects...
...

[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install
[INFO] Scanning for projects...
...

[~/src/jgit] $ cd ../egit

[~/src/egit] $ mvn clean install
[INFO] Scanning for projects...
...

[~/src/jgit] $ cd ../egit-github

[~/src/egit-github] $ mvn clean install
[INFO] Scanning for projects...
...

The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes that egit and jgit source trees are located under a common parent folder. If this is not the case the path to the jgit p2 repository has to be injected via system property:

[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/jgit/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/target/repository

in the same way you can configure a custom path for the build of egit-github to the egit p2 repository

[~/src/egit-github] $ mvn clean install -Degit-site=file:/path/to/egit/org.eclipse.egit.repository/target/repository

The Jenkins build uses (for SNAPSHOT builds):

[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/
                     org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/

If you wan to build EGit for a specific Eclipse platform use the corresponding EGit target platform. For instance, to build for Eclipse 4.19 (2021-03), use the egit-4.19 target platform:

[~/src/egit] $ mvn -Dtarget-platform=egit-4.19 clean install

See the contents of bundle org.eclipse.egit.target for the available target platforms.

Upon a successful build, a p2 update site should be generated inside egit/org.eclipse.egit.repository/target/repository. If not, make sure the target platform has been downloaded from within Eclipse (Windows>Preferences>Plug-in Development>Target Platform). The default target platform defined in the maven build is currently Eclipse 4.6 (Neon). If you skip setting the system property target-platform the target platform for Eclipse 4.6 will be used. EGit built with that target platform can run on any Eclipse >= 4.6. If you choose a higher target platform, the EGit produced may not run on Eclipses older than the target platform version.

Dependencies and License Check

In order to update the list of dependencies run the dash-licenses Maven plugin

mvn org.eclipse.dash:license-tool-plugin:license-check -Ddash.summary=DEPENDENCIES -Ddash.projectId=technology.jgit
mvn org.eclipse.dash:license-tool-plugin:license-check -Ddash.summary=DEPENDENCIES -Ddash.projectId=technology.egit

for jgit and egit and then sort the entries in the file DEPENDENCIES and check for changes against the previous version. If necessary file CQs for new dependencies which are flagged restricted by the tool. See the Eclipse projects handbook.

This tool requires Java 11.

JGit Bazel Build

Since Gerrit is built using Bazel a Bazel build was also implemented for JGit. This simplifies working on Gerrit features which also require changes in JGit.

bazel build :all
bazel test //...
bazel test --test_tag_filters=api,dfs,revplot,treewalk //...
bazel test //... --cache_test_results=NO
bazel test //... --jobs=4
bazel test --test_output=streamed --test_filter=<fully qualified test method> <test target>

e.g.

bazel test --test_output=streamed --test_filter=org.eclipse.jgit.api.GitConstructionTest.testClose //org.eclipse.jgit.test:org_eclipse_jgit_api_GitConstructionTest
bazel test --runs_per_test=3 <test target>
bazel build --java_toolchain //tools:error_prone_warnings_toolchain :all

Note that the Bazel build does not yet support building JGit OSGi bundles, Eclipse features and the p2 repository which are required to install JGit in Eclipse.

Updating build version

use the tools/version.sh script to update the build version in all build files, e.g.

./tools/version.sh --snapshot=6.2.0-SNAPSHOT

FindBugs and PMD

As part of the build, JGit and EGit run FindBugs and PMD to find issues.

Checking for JGit API Changes using API Baseline

The JGit projects have API tooling enabled. In order to use PDE API tools to get assistance with maintaining API changes and additions you need to set an API baseline:

Signing and Publishing

EGit and JGit builds running on the JGit/EGit Jenkins instances are automatically signed (using the CBI eclipse-jarsigner-plugin) and published to the folder

master branch:         /home/data/httpd/download.eclipse.org/egit/updates-nightly
latest stable branch:  /home/data/httpd/download.eclipse.org/egit/updates-stable-nightly

Creating a release

Use the tools/release.sh script to create a new release, e.g.

./tools/release.sh v6.1.0.202203080745-r

Release Notes

We create a release record for each release in the Eclipse project portal and publish release notes there.

New and Noteworthy

For major and minor releases (e.g. 6.0.0, 6.3.0) we create a New and Noteworthy page

Contribution to Release Train

We participate in the Eclipse simultaneous release and its schedule.

The release train contribution for JGit and EGit is maintained in the git repository

ssh://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git

in the files

simrel.aggr
egit.aggrcon

Checkout the master branch and update the versions of jgit and egit to be contributed and the URL of the new version.

Milestones (version ends with -m1, -m2, -m3) and release candidates (version ends with -rc1) are deployed on the download server to egit/staging/<tag name>, the final release (version ends with -r) goes to egit/updates-<major version>.<minor version>[.<micro version>]. The releases on the download server can be browsed here. Old releases are moved to the archive server. Committers can trigger archiving on this page.

All these builds are deployed to the corresponding release repositories on nexus. Maven artefacts:

Corresponding p2 repositories are exposed dynamically using the Nexus Unzip Plugin:

Final releases of jgit are also deployed to Maven central using Sonatype's OSS Nexus using some scripts located in the jgit repository under tools/maven-central.

Open simrel.aggr using the CBI aggregator editor to edit these files. This editor knows the structure of these files and can check their validity.

Push the change for review, review and submit it when the verification build job has voted +1 on verified. Note that the simultaneous release repository only accepts fast-forward submits. This means if another project's change has been submitted you may have to rebase your change.

The release train build is coordinated on the cross-project-issues-dev mailing list.