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:
- Infrastructure as Code - To host, build, test and deploy variants of OpenJDK (aka Java)! This infrastructure as code is designed to be usable by any person or organisation wishing to build a derivative build farm or parts of one.
- Professionally built OpenJDK binaries - A place for end users to download professionally built and tested OpenJDK binaries.
- A Community of builders - A place where those who build and test OpenJDK come together to share common code and practices.
See our https://www.adoptopenjdk.net for in depth details of the motivation, who's involved, the sponsors and much more!
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:
- Technical Steering Committee (TSC) - The Technical Steering Committee and Knowledge Base starting point
- openjdk-infrastructure - Infrastructure as Code and documentation for build farm hosts
- openjdk-jenkins-helper - A auto label generator for Jenkins
- openjdk-build - Code and instructions for building Adopt OpenJDK Binaries
- openjdk-docker - Scripts for creating Docker images of OpenJDK binaries
- openjdk-installer - Installer files for creating platform packaged OpenJDK binaries
- jdk-api-diff - A diff tool that reports what API changes there are between versions
- openjdk-tests - Code and instructions for testing Adopt OpenJDK Binaries
- openjdk-systemtests - Code and instructions for load, app, performance testing AdoptOpenJDK Binaries
- openjdk-stf - The System Test Framework for executing openjdk-systemtests
- See Private Repos for JCK related test repos
- openjdk-website - Code and instructions for https://www.adoptopenjdk.net
- openjdk-api - Code and instructions for https://api.adoptopenjdk.net
- openjdk-api-java-client - A Java client for our API
- openjdk-website-backend - Code for pulling the GitHub releases API into the website
- openjdk-api - Code and instructions for https://api.adoptopenjdk.net
- openjdk8-releases - AdoptOpenJDK main binary releases for OpenJDK 8 with HotSpot
- openjdk8-openj9-releases - AdoptOpenJDK main binary releases for OpenJDK 8 with Eclipse OpenJ9
- openjdk9-releases - AdoptOpenJDK main binary releases for OpenJDK 9 with HotSpot
- openjdk9-openj9-releases - AdoptOpenJDK main binary releases for OpenJDK 9 with Eclipse OpenJ9
- openjdk10-releases - AdoptOpenJDK main binary releases for OpenJDK 10 with HotSpot
- openjdk10-openj9-releases - AdoptOpenJDK main binary releases for OpenJDK 10 with Eclipse OpenJ9
- openjdk8-nightly - AdoptOpenJDK main binary nightlies for OpenJDK 8 with HotSpot
- openjdk8-openj9-nightly - AdoptOpenJDK main binary nightlies for OpenJDK 8 with Eclipse OpenJ9
- openjdk9-nightly - AdoptOpenJDK main binary nightlies for OpenJDK 9 with HotSpot
- openjdk9-openj9-nightly - AdoptOpenJDK main binary nightlies for OpenJDK 9 with Eclipse OpenJ9
- openjdk10-nightly - AdoptOpenJDK main binary nightlies for OpenJDK 10 with HotSpot
- openjdk10-openj9-nightly - AdoptOpenJDK main binary nightlies for OpenJDK 10 with Eclipse OpenJ9
- openjdk-amber-nightly - AdoptOpenJDK project Amber nightlies
When an OpenJDK variant is mercurial based or AdoptOpenJDK needs to maintain its own patches then we have a clone of that source:
- openjdk-jdk8u
- openjdk-jdk9 - TODO move this to jdk9u
- openjdk-jdk10
- openjdk-jfx
- openjdk-amber
Due to security or licensing concerns the following repos are private. Please raise an issue on the Infrastructure Project if you think you need access.
- secrets - For holding some secrets
- JCK - documentation, issues and materials that running a JCK (independent of version)
- JCK8 - code and documentation for running JCK8
- JCK9 - code and documentation for running JCK9
- JCK10 - code and documentation for running JCK10
- JCK-results - for storing JCK results
- openjdk-website-staging - for staging website PR's
TBA - Diagrams to come
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.
- OpenJDK HotSpot Mirrors - GitHub mirrors of OpenJDK forests are created in the AdoptOpenJDK org. For example:
openjdk-jdk8u, openjdk-jdk9,
openjdk-jdk10, openjdk-amber. Please open an
openjdk-TSC issue if you'd like a new variant added.
- git-hg Jobs Update Mirrors - Our Jenkins CI runs git-hg jobs to regularly update those various clones of OpenJDK forests. See their job configurations in Jenkins and the openjdk-build repo for details.
- OpenJDK OpenJ9 - Eclipse OpenJ9 source is built from IBM Runtimes, e.g. openj9-openjdk-jdk8, openj9-openjdk-jdk9
- OpenJDK SAP - SAP source is built from e.g. openjdk-sap-jdk10
- OpenJDK OpenJFX - GitHub mirror of OpenJDK JFX lives at AdoptOpenJDK - openjdk-jfx
Each OpenJDK variant has a canonical branch that is built:
- OpenJDK HotSpot - The
devbranch of AdoptOpenJDK contains extra patches over and abovemaster(which is the exact clone of the OpenJDK forest).devis used to build AdoptOpenjDK binaries - OpenJDK OpenJ9 - Branches such as
openj9-0.8are used to build OpenJ9 Releases for Java 8 andopenj9is used to build OpenJ9 for Java 9. - OpenJDK SAP - The
sapmachinebranch is used to build SAP for Java 10 - OpenJDK OpenJFX - TODO
Our 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 binarues are released to Nightly and Release repos 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.
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.
- Builds are tested - The tests in openjdk-tests are executed and tests results are posted to TODO.
Tests include, but are not limited to the jtreg tests that come with OpenJDK itself. - Builds are system tested - System Tests from openjdk-systemtests are executed and test results are posted to TODO
- Builds are (J)TCK tested - TCK (JCK) tests are executed and success / failure is reported to TODO. Note that internal details cannot be disseminated to the public due to the TCK licensing agreement.
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-webiste-backend project) in order to:
- deploy them to the various nightly repos: (openjdk8-nightly, openjdk8-openj9-nightly, openjdk9-nightly, openjdk9-openj9-nightly, openjdk10-nightly, openjdk10-openj9-nightly) and release repos: (openjdk8-releases, openjdk8-openj9-releases, openjdk9-releases, openjdk9-openj9-releases, openjdk10-releases, openjdk10-openj9-releases)
- 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.
NOTE This section is a DRAFT and has not yet been fully discussed or ratified by the AdoptOpenJDK community at large.
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:
- Managing code and documentation creation and changes for the listed projects and resources
- Meeting monthly to discuss progress and other TSC issues
- Setting and maintaining standards covering contributions of code, documentation and other materials
- Managing code and binary releases: types, schedules, frequency, delivery mechanisms
- Creating new repositories and projects under the AdoptOpenJDK GitHub organisation as required
- Setting overall technical direction for the AdoptOpenJDK organisation, including high-level goals and low-level specifics regarding features and functionality
- Has a relationship with the AdoptOpenJDK security group for dealing with vulnerabilities in an appropriate manner
- Setting and maintaining appropriate standards for community discourse via the various mediums under TSC control
TSC members can nominate new members at any time. Candidates for membership tend to be people who have a competency for community management and a high tolerance and patience for process minutiae as the TSC delegates most of its responsibilities to other teams.
Every Dependant Project not currently incubating can appoint someone to the TSC who they elect at their own discretion.
| Avatar | Information |
|---|---|
| TBA | TBA |
- No single company can occupy more than 1/3 seats on the TSC
- The appointing of TSC members occurs on an annual basis and is based on a meritocracy.
- Candidates with the intention of becoming a member of the TSC should briefly outline where they'd like to see the project going - all in a transparent manner that is available to the public.
Thanks! The AdoptOpenJDK Community.