We welcome any contributions big or small from experienced OpenJDK folks to those who are brand new to software projects!
To start, make sure you sign up to the AdoptOpenJDK Slack, say hello and please read the Contribution Guide.
The AdoptOpenJDK Build Farm is three things:
See https://www.adoptopenjdk.net for in depth details of the motivation, who's involved, the sponsors and much more!
AdoptOpenJDK is a vast undertaking and has numerous GitHub repositories where the work gets done.
These projects are located in the following repositories in rough order of importance with regards to understanding how the build farm is put together and works. Each repository maintains its own set of issues, pull requests and documentation (edit the Image Source and export to make changes.)
openjdk-website-backend
. Code for pulling the GitHub releases API into the website.These projects are critical to maintaining security, supporting our user ecosystem, and for the internal running of the project (edit the Image Source at Google and export to make changes.)
The following diagram lists the source repositories for AdoptOpenJDK (edit the Image Source at Google and export to make changes.)
When an OpenJDK variant is mercurial based or AdoptOpenJDK needs to maintain its own patches then we have a clone of that source:
The following diagram lists the binary repositories for AdoptOpenJDK (edit the Image Source at Google and export to make changes.). These GitHub Repositories are where builds that pass the pipeline are published to. The API (and subsequently) website poll these repositories to make binaries available.
These GitHub Repositories are where builds from the OpenjDK update projects (led by Red Hat) are published to. The API (and subsequently) website poll these repositories to make binaries available.
These GitHub Repositories are where builds from Alibaba's Dragonwell distribution are published to. The API (and subsequently) website poll these repositories to make binaries available.
Due to security or licensing concerns the following repositories are private. Please raise an issue on the Infrastructure Project if you think you need access.
We support the building of Java Mission Control (JMC).
The following diagram is a very simplified view of how a build progresses through a pipeline (edit the Image Source at Google and export to make changes.)
NOTE: Please ensure you read the documentation below and in the appropriate repositories to get a full understanding
The workflow to source, build, test and deploy variants of OpenJDK is as follows.
We source variants and versions of OpenJDK from a variety of source repositories. Add a new build variant describes the typical work flow of getting a new variant up and running. Please also see Platform Costs as variants with high impact on the build farm will require funding.
Each OpenJDK variant has a canonical branch that is built:
dev
branch of AdoptOpenJDK contains extra patches over and above master
(which is the exact clone of the OpenJDK forest).
dev
is used to build AdoptOpenJDK binariesopenj9-0.8
are used to build OpenJ9 Releases for Java 8 and openj9
is used to build OpenJ9 for Java 9.sapmachine
branch is used to build SAP for Java 10Our Jenkins Pipelines (source code) build binaries and then push them through a test pipeline (NOTE Test pipeline is skipped for certain unstable combinations).
NOTE: Once the Test jobs have stabilised, the pipeline described below will change so that only tested binaries are released to Nightly and Release repositories for consumption by the Website and/Or API. See The Quality Bar Discussion for details.
Builds are run on the Supported Platforms. The Jenkins leader sends the build jobs to the Jenkins followers based on a tagging system configured in the Jenkins jobs, e.g. centos6&&x64&&build
. See openjdk-build and openjdk-infrastructure for details.
Note that other OpenJDK binaries (such as the openjdk8-upstream-binaries and openjdk11-upstream-binaries) can be put through pipelines entering at this Test phase.
Tests are run on the Supported Test Platforms. The Jenkins leader sends the test jobs to the Jenkins followers based on a similar tagging system to build. See openjdk-tests and openjdk-infrastructure for details.
TODO - Binaries are signed.
TODO: We're missing the SAP and OpenJFK deployments here.
NOTE Future versions of this workflow will show the status of testing and meta data about how the binary was built.
Binaries are deployed - Using the OpenJDK Release Tool (from the openjdk-website-backend project) in order to:
Binaries made available - Binaries are made available for download via the website and api gateway. See openjdk-website, openjdk-api and openjdk-api-java-client projects for more details. We also make the builds available through DockerHub and our own unofficial docker repositories, see openjdk-docker for details.
The TSC exercises autonomy in setting up and maintaining procedures, policies, and management and administrative structures as it deems appropriate for the maintenance and operation of these projects and resources.
Included in the responsibilities of the TSC are:
TSC members can nominate new members at any time. Candidates for membership tend to be people who have a competency for community management and high tolerance and patience for process minutiae as the TSC delegates most of its responsibilities to other teams.
Director | Chair |
---|---|
karianna - Martijn Verburg (Microsoft) |
gdams - George Adams (Microsoft) |
Members | ||
---|---|---|
aahlenst - Andreas Ahlenstorf (ZHAW) |
gdams - George Adams (Microsoft) |
hendrikebbers - Hendrik Ebbers (Karakun AG) |
jerboaa - Severin Gehwolf (Red Hat) |
johnoliver - John Oliver (Microsoft) |
karianna - Martijn Verburg (Microsoft) |
smlambert - Shelley Lambert (Red Hat) |
sxa - Stewart X Addison (Red Hat) |
tellison - Tim Ellison (Red Hat) |
Each community member has a Single Transferable Vote (STV). There are tools to manage STV voting.
Thanks!
The AdoptOpenJDK Community.