Eclipse Temurin™ build scripts - common across all releases/versions

Overview

Repository for code and instructions for building OpenJDK binaries, defaulting to Eclipse Temurin™

These scripts can be used to build OpenJDK anywhere but are primarily used by Eclipse Adoptium members (vendors) to build binaries. The scripts default to the use case of building Eclipse Temurin binaries which occurs on the build farm at https://ci.adoptopenjdk.net. Those binaries are then made available for consumption at https://adoptium.net and via the API https://api.adoptium.net.

NOTE In the future, adoptium.net will transition to being a marketplace for other qualifying vendors as well Eclipse Temurin.

Where can I find the release status of Eclipse Temurin™ binaries?

Go to the Eclipse Adoptium Top Level Project Repo for release tracking.

TL;DR: I want to build a JDK NOW

Build jdk natively on your system

To do this you will need to have your machine set up with a suitable compiler and various other tools available. We set up our machines using ansible playbooks from the openjdk-infrastructure repository. You can also look at the dockerfile generator for a list of required packages for Ubuntu.

Once you've got all of the prerequisites installed, clone this openjdk-build repository (git clone https://github.com/adoptium/temurin-build and kick off a build a follows with this script. The -J parameter specifies the "boot JDK" which should generally be one major version prior to the one you are building (although one of the same major version will also work). Note that the build variant defaults to HotSpot if omitted which builds from the same repositories as Temurin.

./makejdk-any-platform.sh (-J /usr/lib/jvm/jdk-xx) (--build-variant <hotspot|openj9|corretto|SapMachine|dragonwell|bisheng>) <jdk8u|jdk11u|jdk16u|jdk>

e.g.

./makejdk-any-platform.sh -J /usr/lib/jvm/jdk-10.0.2 --build-variant hotspot jdk11u

How do I build OpenJDK in a docker image?

If you do not want to set up your machine with all the prerequisites for building OpenJDK, you can use our docker images under the [docker] directory as follows (first version builds HotSpot, second builds J9 - the final parameter can be adjusted to build whichever version you want as long as we can generate valid dockerfile for it):

./makejdk-any-platform.sh --docker --clean-docker-build jdk8u
./makejdk-any-platform.sh --docker --clean-docker-build --build-variant openj9 jdk11u

We test these dockerfiles on a regular basis in the Dockerfilecheck job to ensure they continue to work in a stable fashion.

Repository contents

This repository contains several useful scripts in order to build OpenJDK personally or at build farm scale.

  1. The build-farm folder contains shell scripts for multi configuration Jenkins build jobs used for building Adopt OpenJDK binaries.
  2. The docker folder contains tools for generating dockerfiles which can be used as part of building OpenJDK inside a Docker container.
  3. The git-hg folder has now been moved to it's own separate repository. See openjdk-mirror-scripts.
  4. The pipelines folder has now been moved to a separate repo: https://github.com/adoptium/ci-jenkins-pipelines.
  5. The sbin folder contains the scripts that actually build (Temurin). build.sh is the entry point which can be used stand alone but is typically called by the native-build.sh or docker-build.sh scripts (which themselves are typically called by makejdk-any-platform.sh).
  6. The security folder contains a script and cacerts file that is bundled with the JDK and used when building OpenJDK: the cacerts file is an important file that's used to enable SSL connections.

The makejdk-any-platform.sh script

makejdk-any-platform.sh is the entry point for building (Adopt) OpenJDK binaries. Building natively or in a docker container are both supported. This script (and its supporting scripts) have defaults, but you can override these as needed. The scripts will auto detect the platform and architecture it is running on and configure the OpenJDK build accordingly. The supporting scripts will also download and locally install any required dependencies for the OpenJDK build, e.g. The ALSA sound and Freetype font libraries.

Many of the configuration options are passed through to the configure and make commands that OpenJDK uses to build binaries. Please see the appropriate README-builds.html file for the OpenJDK source repository that you are building.

NOTE: Usage can be found via makejdk-any-platform.sh --help. Here is the man page re-formatted for convenience.

USAGE

./makejdk-any-platform [options] version

Please visit https://www.adoptium.net for further support.

VERSIONS

jdk8u - Build Java 8, defaults to https://github.com/adoptium/jdk8u
jdk11u - Build Java 11, defaults to https://github.com/adoptium/jdk11u
jdk16u - Build Java 16, defaults to https://github.com/adoptium/jdk16u
jdk - Build Latest Java (Alpha/Beta), defaults to https://github.com/adoptium/jdk

OPTIONS

-b, --branch <branch>
specify a custom branch to build from, e.g. dev.
For reference, Adoptium GitHub source repositories default to the dev
branch which may contain a very small diff set to the master branch
(which is a clone from the OpenJDK mercurial forest).

-B, --build-number <build_number>
specify the OpenJDK build number to build from, e.g. b12.
For reference, OpenJDK version numbers look like 1.8.0_162-b12 (for Java 8) or
9.0.4+11 (for Java 9+) with the build number being the suffix at the end.

--build-variant <variant_name>
specify a OpenJDK build variant, e.g. openj9.
For reference, the default variant is hotspot and does not need to be specified.

-c, --clean-docker-build
removes the existing docker container and persistent volume before starting
a new docker based build.

-C, --configure-args <args>
specify any custom user configuration arguments, using 
temporary_speech_mark_placeholder in the place of any speech marks.

--clean-git-repo
clean out any 'bad' local git repo you already have.

--create-debug-image
create a debug-image archive with the debug symbols.

--create-jre-image
create the legacy JRE image in addition to the JDK image.

-d, --destination <path>
specify the location for the built binary, e.g. /path/.
This is typically used in conjunction with -T to create a custom path
/ file name for the resulting binary.

-D, --docker
build OpenJDK in a docker container.

--cross-compile
use this if you are cross compiling - it will skip the java -version checks at the end

--debug-docker
debug OpenJDK build script in a docker container. Only valid if -D is selected.

--disable-shallow-git-clone
disable the default fB--depth=1 shallow cloning of git repo(s).

-f, --freetype-dir
specify the location of an existing FreeType library.
This is typically used in conjunction with -F.

--freetype-build-param <parameter>
specify any special freetype build parameters (required for some Operating Systems).

--freetype-version <version>
specify the version of freetype you are building.

-F, --skip-freetype
skip building Freetype automatically.
This is typically used in conjunction with -f.

-h, --help
print the man page.

-i, --ignore-container
ignore the existing docker container if you have one already.

-J, --jdk-boot-dir <jdk_boot_dir>
specify the JDK boot dir.
For reference, OpenJDK needs the previous version of a JDK in order to build
itself. You should select the path to a JDK install that is N-1 versions below
the one you are trying to build.

-k, --keep
if using docker, keep the container after the build.

--make-exploded-image
creates an exploded image (useful for codesigning jmods). Use --assemble-exploded-image once you have signed the jmods to complete the packaging steps.

--custom-cacerts <true|false>
If true (default), a custom cacerts file will be generated based on the Mozilla list of CA certificates (see folder security/). If false, the file shipped by OpenJDK will be used. 

-n, --no-colour
disable colour output.

-p, --processors <args>
specify the number of processors to use for the docker build.

-r, --repository <repository>
specify the repository to clone OpenJDK source from,
e.g. https://github.com/karianna/openjdk-jdk8u.

-s, --source <path>
specify the location to clone the OpenJDK source (and dependencies) to.

-S, --ssh
use ssh when cloning git.
In case of docker build add github.com to ~/.ssh/known_hosts (e.g.: ssh github.com)
if your ssh key has a passphrase, add it to ssh-agent (e.g.: ssh-add ~/.ssh/id_rsa)

--sign
sign the OpenJDK binary that you build.

--sudo
run the docker container as root.

-t, --tag <tag>
specify the repository tag that you want to build OpenJDK from.

-T, --target-file-name <file_name>
specify the final name of the OpenJDK binary.
This is typically used in conjunction with -D to create a custom file
name for the resulting binary.

--tmp-space-build
use the temp directory for performing the build

-u, --update-version <update_version>
specify the update version to build OpenJDK from, e.g. 162.
For reference, OpenJDK version numbers look like 1.8.0_162-b12 (for Java 8) or
9.0.4+11 (for Java 9+) with the update number being the number after the '_'
(162) or the 3rd position in the semVer version string (4).
This is typically used in conjunction with -b.

--use-jep319-certs
Use certs defined in JEP319 in Java 8/9. Deprecated, has no effect.

-v, --version
specify the OpenJDK version to build e.g. jdk8u.  Left for backwards compatibility.

-V, --jvm-variant <jvm_variant>
specify the JVM variant (server or client), defaults to server.

Example usage:

./makejdk-any-platform --docker jdk8u
./makejdk-any-platform -T MyOpenJDK10.tar.gz jdk10

Script Relationships

Build Variant Workflow

The main script to build OpenJDK is makejdk-any-platform.sh, which itself uses and/or calls configureBuild.sh, docker-build.sh and/or native-build.sh.

The structure of a build is:

  1. Configuration phase determines what the configuration of the build is based on your current platform and and optional arguments provided
  2. Configuration is written out to config/built_config.cfg
  3. Build is kicked off by either creating a docker container or running the native build script
  4. Build reads in configuration from built_config.cfg
  5. Downloads source, dependencies and prepares build workspace
  6. Invoke OpenJDK build via make
  7. Package up built artifacts

Building OpenJDK from other locations

Building OpenJDK from a non-Adoptium repository

These scripts default to using Adoptium as the OpenJDK source repo to build from, but you can override this with the -r flag. If you want to run from a non-default branch you can also specify -b e.g.

./makejdk-any-platform.sh -r https://github.com/sxa/openjdk-jdk8u -b main -J /usr/lib/jvm/java-1.7.0 jdk8u

Building in a custom directory

Example Usage

./makejdk-any-platform.sh -J /usr/lib/jvm/jdk-10.0.2 -s $HOME/openjdk-jdk11u/src -d $HOME/openjdk-jdk11u/build -T MyOpenJDK11.tar.gz jdk11u

This would clone OpenJDK source from https://github.com/adoptium/openjdk-jdk11u to $HOME/openjdk-jdk11u/src, configure the build with sensible defaults according to your local platform and then build OpenJDK and place the result in /home/openjdk/target/MyOpenJDK11.tar.gz.

Metadata

Alongside the built assets a metadata file will be created with info about the build. This will be a JSON document of the form:

{
    "vendor": "Eclipse Adoptium",
    "os": "mac",
    "arch": "x64",
    "variant": "openj9",
    "variant_version": {
        "major": "0",
        "minor": "22",
        "security": "0",
        "tags": "m2"
    },
    "version": {
        "minor": 0,
        "security": 0,
        "pre": null,
        "adopt_build_number": 0,
        "major": 15,
        "version": "15+29-202007070926",
        "semver": "15.0.0+29.0.202007070926",
        "build": 29,
        "opt": "202007070926"
    },
    "scmRef": "<output of git describe OR buildConfig.SCM_REF>",
    "buildRef": "<build-repo-name/build-commit-sha>",
    "version_data": "jdk15",
    "binary_type": "debugimage",
    "sha256": "<shasum>",
    "full_version_output": "<output of java --version>",
    "configure_arguments": "<output of bash configure>"
}

The Metadata class is contained in the Metadata.groovy file and the Json is constructed and written in the openjdk_build_pipeline.groovy file.

It is worth noting the additional tags on the semver is the adopt build number.

Below are all of the keys contained in the metadata file and some example values that can be present.


  • vendor: Example values: [Eclipse Adoptium, Alibaba]

This tag is used to identify the vendor of the JDK being built, this value is set in the build.sh file and defaults to "Adoptium".


  • os: Example values: [windows, mac, linux, aix, solaris]

This tag identifies the operating system the JDK has been built on (and should be used on).


  • arch: Example values: [aarch64, ppc64, s390x, x64, x86-32, arm]

This tag identifies the architecture the JDK has been built on and it intended to run on.


  • variant: Example values: [hotspot, openj9, corretto, dragonwell, bisheng]

This tag identifies the JVM being used by the JDK. "dragonwell" and "bisheng" itself are HotSpot based JVMs but are currently considered their own variants for the purposes of build. WARN: This will be changed at a later date when we split out JVM from vendor.


  • variant_version:

This tag is used to identify a version number of the variant being built, it currently is exclusively used by OpenJ9 and has the following keys:

  • major: Example values: [0, 1]

  • minor: Example values: [22, 23, 24]

  • security: Example values: [0, 1]

  • tags: Example values: [m1, m2]


  • version:

This tag contains the full version information of the JDK built, it uses the VersionInfo.groovy class and the ParseVersion.groovy class.

It contains the following keys:

  • minor: Example values: [0]

  • security: Example Values: [0, 9, 252 272]

  • pre: Example values: [null]

  • adopt_build_number: Example values: [0]
    If the ADOPT_BUILD_NUMBER parameter is used to build te JDK that value will appear here, otherwise a default value of 0 appears.

  • major: Example values: [8, 11, 15, 16]

  • version: Example values: [1.8.0_272-202010111709-b09, 11.0.9+10-202010122348, 14.0.2+11-202007272039, 16+19-202010120348]

  • semver: Example values: [8.0.202+8.0.202008210941, 11.0.9+10.0.202010122348, 14.0.2+11.0.202007272039, 16.0.0+19.0.202010120339]
    Formed from the major, minor, security, and build number by the formSemver() function.

  • build: Example values: [6, 9, 18]
    The OpenJDK build number for the JDK being built.

  • opt: Example values: [202008210941, 202010120348, 202007272039]


  • scmRef: Example values: [dragonwell-8.4.4_jdk8u262-b10, jdk-16+19_adopt-61198-g59e3baa94ac, jdk-11.0.9+10_adopt-197-g11f44f68c5, 23f997ca1]

A reference the the base JDK repository being build, usually including a Github commit reference, i.e. jdk-16+19_adopt-61198-g59e3baa94ac links to https://github.com/adoptium/openjdk-jdk/commit/59e3baa94ac via the commit SHA 59e3baa94ac.

Values that only contain a commit reference such as 23f997ca1 are OpenJ9 commits on their respective JDK repositories, for example 23f997ca1 links to the commit https://github.com/ibmruntimes/openj9-openjdk-jdk14/commit/23f997ca1.


  • buildRef: Example values: [openjdk-build/fe0f2dba, openjdk-build/f412a523]
    A reference to the build tools repository used to create the JDK, uses the format repository-name/commit-SHA.

  • version_data: Example values: [jdk8u, jdk11u, jdk14u, jdk]

  • binary_type: Example values: [jdk, jre, debugimage, testimage]

  • sha256: Example values: [20278aa9459e7636f6237e85fcd68deec1f42fa90c6c541a2dfa127f4156d3e2, 2f9700bd75a807614d6d525fbd8d016c609a9ea71bf1ffd5d4839f3c1c8e4b8e]
    A SHA to verify the contents of the JDK.

  • full_version_output: Example values:
openjdk version \"1.8.0_252\"\nOpenJDK Runtime Environment (Alibaba Dragonwell 8.4.4) (build 1.8.0_252-202010111720-b06)\nOpenJDK 64-Bit Server VM (Alibaba Dragonwell 8.4.4) (build 25.252-b06, mixed mode)\n`

The full output of the command java -version for the JDK.


  • configure_arguments: The full output generated by configure.sh for the JDK built.
Comments
  • MacOS hardened runtime support

    MacOS hardened runtime support

    I would like to bundle the AdoptOpenJDK into a MacOS application. To use Apple's notary service all executables in my app have to be codesigned with hardened runtime support.

    The ApoptOpenJDK executables are codesigned already, but unfortunately without hardened runtime support.

    I can re-sign them myself like this:

    codesign --verbose --options runtime --force --sign "Developer ID Application: SecSign Technologies Inc." bin/java

    but apparently this damages the executables. For example "java" is not able to print its version any more:

    java --version
    Error occurred during initialization of VM
    Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)
    

    Would the ApoptOpenJDK team be able to enable the hardened runtime ("--options runtime") during the codesigning in the build process of the AdoptOpenJDK? This would be great.

    Thank you in advance for any comments on this issue.

    Kind regards Tilo

    enhancement 
    opened by tkie 120
  • JavaFX is missing in OpenJDK 8 Distributions

    JavaFX is missing in OpenJDK 8 Distributions

    Hallo,

    currently JavaFX libraries are missing from the OpenJDK 8 Windows Distributions. Is there a plan to include JavaFX in the AdoptOpenJDK Distributions?

    Many thanks in advance for your help!

    enhancement wontfix 
    opened by SzentnerTsIT 118
  • Should Adoptium be producing Temurin JREs for releases beyond version 8?

    Should Adoptium be producing Temurin JREs for releases beyond version 8?

    We all agree that Temurin 8 should have both a JDK and JRE build available, but what about later versions?

    With jlink being introduced alongside modularity, there is a new way to strip down the Java runtime to minimize the delivery in a way that specifically supports the application. Users can also jlink a 'general purpose' runtime environment for multiple applications to share.

    AdoptOpenJDK produced JREs and JDKs based OpenJDK 11. Should Adoptium continue this for Temurin, or drop the concept of JREs beyond Temurin 8? This would be a regression for users of the AdoptOpenJDK JREs when moving to Temurin builds.

    enhancement question 
    opened by tellison 114
  • Parameterized Generators and Pipelines

    Parameterized Generators and Pipelines

    • Users can now generate their own pipelines using this script from their own repositories to where they want to generate them.
    • Implement repository checkouts to switch between user and adopt files
    • Implement a default params system that allows for more freedom and configuration for the user
    • Relevant doc and styling updates

    Closes: #2116 Signed-off-by: Morgan Davies [email protected]

    enhancement documentation refactoring testing regeneration 
    opened by M-Davies 56
  • Prototype

    Prototype "Reproducible Build" using current available Adopt jenkins job & infra framework and "build info"

    This is a work item for EPIC https://github.com/AdoptOpenJDK/openjdk-build/issues/2522. The aim being to "prototype" an initial attempt at being able to "recreate" an Adopt build based on specifying the basic "build info" currently available for an existing "release", and assuming the current available "infra" setup.

    Design:

    Assumptions for 1st prototype:

    1. Hotspot only
    2. no installer
    3. no signing

    Spec: Extend the current openjdk-pipeline & build jobs to take as extra inputs basic "build info":

    • Openjdk "mirror" source git "commit SHA" or "tag"
    • openjdk-build repo SHA
    • ci-jenkins-pipelines repo SHA
    enhancement jenkins infra installer compatibility reproducible-build 
    opened by andrew-m-leonard 55
  • How to update timezone data with AdoptOpenJDK

    How to update timezone data with AdoptOpenJDK

    I have been trying to update timezone data within the latest AdoptOpenJDK 11 image, however Oracle's tzupdater does not appear to work, crashing with a null pointer exception. Is there a recommended way to update timezones with AdoptOpenJDK?

    bug blocked 
    opened by keirlawson 50
  • aarch64 build failure, Hash of java.rmi (...) differs to expected hash

    aarch64 build failure, Hash of java.rmi (...) differs to expected hash

    Platform: aarch64 https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-linux-aarch64-openj9-linuxXL/223/consoleFull

    01:05:10  * For target support_images_jre:
    01:05:10  Error: Hash of java.rmi (5fe5f05db30334fea7371af06d42a7f7e5417acae4022df3ddec5c8d8aaf5e02) differs to expected hash (24f0620202e6705b53c79e3827358915385f2c46b4c91b1b65443e954b4df58f) recorded in java.base
    01:05:10  java.lang.module.FindException: Hash of java.rmi (5fe5f05db30334fea7371af06d42a7f7e5417acae4022df3ddec5c8d8aaf5e02) differs to expected hash (24f0620202e6705b53c79e3827358915385f2c46b4c91b1b65443e954b4df58f) recorded in java.base
    01:05:10  	at java.base/java.lang.module.Resolver.findFail(Resolver.java:877)
    01:05:10  	at java.base/java.lang.module.Resolver.checkHashes(Resolver.java:461)
    01:05:10  	at java.base/java.lang.module.Resolver.finish(Resolver.java:360)
    01:05:10  	at java.base/java.lang.module.Configuration.<init>(Configuration.java:141)
    01:05:10  	at java.base/java.lang.module.Configuration.resolve(Configuration.java:424)
    01:05:10  	at java.base/java.lang.module.Configuration.resolve(Configuration.java:256)
    01:05:10  	at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:220)
    01:05:10  	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:486)
    01:05:10  	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:396)
    01:05:10  	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:272)
    01:05:10  	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
    01:05:10  	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)
    

    I am suspecting this maybe an openjdk build concurrency issue. Workaround maybe reducing the aarch64 concurrency, it is currently using 29 jobs:

    00:43:14  * Cores to use:   29
    
    bug openj9 x-linux aarch 
    opened by andrew-m-leonard 48
  • Provide native builds for ARM based Macs

    Provide native builds for ARM based Macs

    At WWDC20 Apple announced to move from Intel to ARM chips for Mac hardware. For the Java Community it will be important to support Java on those new devices. At Adopt we should provide native Java builds for the new hardware if possible. This issue can be used to collect information about porting Java to ARM on Mac.

    macos arm 
    opened by hendrikebbers 45
  • Introduce staged timeout system

    Introduce staged timeout system

    All timeouts are now done on a stage by stage basis, failing the build with a helpful message if the timeout is reached:

    TOP LEVEL PIPELINES

    • Adopt api requests = 1 hour
    • Copy artifacts = 6 hours
    • Remove artifacts = 2 hours
    • Archive artifacts = 6 hours
    • Publish artifacts = 3 hours

    DOWNSTREAM JOBS

    • Clean master node = 1 hour
    • Clean aix node = 1 hour
    • Adopt api requests = 1 hour
    • Clean workspace on node = 1 hour
    • Checkout scm on node = 1 hour
    • Pull docker image = 2 hours
    • Checkout docker image = 1 hour
    • Main build script (make-adopt-build-farm.sh) = 6 hours
    • Archive artifact = 3 hours
    • Sign build job = 2 hours
    • Installer jobs = 3 hours
    • I have added the nessasary stubs and libraries to ensure that the try-catch fires correctly when a timeout is reached. For the FlowInterruptedException, it required importing the jenkins core lib via gradle (https://stackoverflow.com/a/47353745/14420589).

    • While I was at it, I also added in a node timeout to the pr tester (since that was a param that got implemented recently https://github.com/AdoptOpenJDK/openjdk-build/issues/2118) as well as correcting the function that ran it to use Jenkins advanced sleep which has more brevity and reliability than normal groovy sleep. I also added a println to when we move into/out-of nodes as it's hard to tell sometimes in the logs

    Closes: #2120 Signed-off-by: Morgan Davies [email protected]

    enhancement jenkins 
    opened by M-Davies 43
  • Download extremely slow. How about sharing torrents to spare bandwidth?

    Download extremely slow. How about sharing torrents to spare bandwidth?

    Trying to download OpenJDK 11, 174 MB at 20 KB/s, 2 hours estimated. Slows down even further (10 KB/s) during the attempt.

    LibreOffice is provided via torrents. Might be useful for this project as well if bandwidth is an issue for you.

    invalid 
    opened by LigH-de 42
  • Switch OpenJ9 builds on JDK11 to mixedref specs

    Switch OpenJ9 builds on JDK11 to mixedref specs

    Mixed refs combines the regular and XL package into one sdk. Also remove the deprecated XL specs from jdk11. Once this is default across all versions there will be more code that can be cleaned up I presume.

    Issue #2426

    Signed-off-by: Adam Brousseau [email protected]

    enhancement wontfix openj9 
    opened by AdamBrousseau 38
  • switch freetype to clone source from GitHub

    switch freetype to clone source from GitHub

    Now that the FreeType source is available in GitHub we should switch to cloning the FreeType source from there rather than relying on our mirror on the Jenkins server. Not only does this mean we don't have to update the mirror each time we bump the version, but it also means that we can use an immutable SHA in the SBOM.

    Checking with @andrew-m-leonard that I've set the details in the SBOM correctly. Ultimately I've switched to us storing https://github.com/freetype/freetype/commit/${FREETYPE_SHA} (matching the way we store other Git refs in the SBOM.

    Note that compiling the FreeType source from GitHub adds a dependency on automake for the macOS builds. This doesn't seem to be present on our current build machines so will need adding (I can submit a PR to the infra repo)

    macos windows 
    opened by gdams 3
  • Reproducible build status table

    Reproducible build status table

    The following are the current reproducible builds:

    | platform | jdk-17 | jdk-19 | jdk-20 | ----- | ----- | ----- | ----- | | x64Linux | | | | | aarch64Linux | | | | | x64Windows | | | | | x64Mac | | | | | aarch64Mac | | | |

    aarch reproducible-build 
    opened by andrew-m-leonard 0
  • Update linux platform SBOMs with full strace tooling dependencies

    Update linux platform SBOMs with full strace tooling dependencies

    This feature is to enable running strace as part of the build, so that the SBOM can feature the complete exact build tooling and dependent libraries were used.

    1. Find suitable section of SBOM format to place dependencies?
    2. Investigate implications of enabling strace on Jenkins Linux nodes?
    3. See issue for details of processing script for strace output
    4. Create plan from investigations and get mentor review
    5. Implement plan
    enhancement x-linux reproducible-build 
    opened by andrew-m-leonard 1
  • SBOM provenance artefact should be signed

    SBOM provenance artefact should be signed

    The SBOM is used to determine the provenance authenticity and integrity of the Temurin binaries, and as such should be able to be verified by the consumer to be authentic.

    This issue is to enhance the build process to include a digital signature of the SBOM artefact using the trusted code signing key.

    This is an obligation of SLSA Level 2.

    enhancement Sbom secure-dev 
    opened by tellison 16
  • Discussion: naming convention for buildReference

    Discussion: naming convention for buildReference

    We should define what the git tag should be formed when we set it on the and used in the official release for input buildReference

    Since they will be used for reproducible build, unless we decided to use SHA instead of tag in the build, we should never move tags around. create new one if needed

    Suggestion:v<YY>.<MM>.01 e.g for 2022 Oct CPU release, v2022.10.01 if any hot bug fix, we can create v2022.10.02 and so on.

    DoD:

    • what the name should be for tag
    • be clear the process: who will apply such tag and when it should be done pre-release
    • update https://github.com/adoptium/temurin-build/blob/master/RELEASING.md#steps-for-every-version

    Ref: https://github.com/adoptium/ci-jenkins-pipelines/issues/495

    jenkins documentation reproducible-build 
    opened by zdtsw 0
Releases(april-psu)
Owner
Eclipse Adoptium
The Adoptium Working Group promotes and supports high-quality runtimes and associated technology for use across the Java ecosystem
Eclipse Adoptium
Mc-msa-token-getter - Scripts to retrieve MC authentication tokens for use in modding dev envs.

Minecraft MSA Token Getter Python and Java scripts to retrieve MC authentication tokens for use in modding dev envs. Requires a properly configured Az

Ryan 1 Jan 3, 2022
This is a plugin for Minecraft Server (Spigot API) introduces a sector system which connects a single world across multiple servers.

OpenSourceSectors ?? ??️ This is a plugin for Minecraft Server (Spigot API) introduces a sector system which connects a single world across multiple s

null 20 Dec 28, 2022
Distribute players across multiple servers while syncing packets

ShardMC Distribute players across multiple servers while syncing packets ShardMC aims to be a simple plugin that allows multiple servers to sync playe

Jacob Bashista 5 Nov 28, 2022
This repo contains all the materials for placement as well as Practical lab codes for all subjects and notes. For students graduating in 2023

UEMK_PLACEMENT_2023 This repo contains all the materials for placement as well as Practical lab codes for all subjects and notes. For students graduat

Shambashib Majumdar 8 Mar 5, 2022
Gitlet - A version control system for managing file versions, mirroring the features of Git

Gitlet - A version control system for managing file versions, mirroring the features of Git. Emphasized the serialization and manipulation of files to compress, access, and manage file content efficiently. Stressed the employment of appropriate data structures and file persistance.

null 1 Jan 4, 2022
A free opensource domain tracker with a breakdown of which countries players connected with for each domain versions 1.13+

A free opensource domain tracker with a breakdown of which countries players connected with for each domain versions 1.13+

Ricky Lafleur 8 Aug 4, 2022
Apache/Alibaba Dubbo <= 2.7.3 PoC Code for CVE-2021-25641 RCE via Deserialization of Untrusted Data; Affects Versions <= 2.7.6 With Different Gadgets

The 0xDABB of Doom - CVE-2021-25641-Proof-of-Concept Apache/Alibaba Dubbo <= 2.7.3 PoC Code for CVE-2021-25641 RCE via Deserialization of Untrusted Da

Dor Tumarkin 51 Apr 24, 2022
SBSRE is an eclipse plugin for extract method refactoring based on the single responsibility principle(SRP)

SBSRE is a slice-based single responsibility extraction approach supported by an eclipse plugin for identifying Single responsibility violations in the methods.

null 4 Jul 8, 2022
A log4j2 plugin to Eclipse.

Ganymede A log4j2 log viewer plugin for Eclipse. Installation Use the Eclipse update site: Ganymede2 - https://dbusche.github.io/Ganymede2/ History Th

null 3 Dec 15, 2022
Repositório que também será utilizado como workspace no eclipse

entra21 Programação orientada a objetos Repositório com as práticas realizadas em aula Conteúdo prático realizado em sala durante o projeto Entra21 Em

Rubem Oliota 10 Jun 8, 2022
A library for common extensions for Truth.

truth-extensions A library for common extensions for Truth. Usage Repository To depend on a release, you need only depend on the official Maven centra

Mardrömmar 2 Jan 24, 2022
A template for a Forge + Fabric project setup using a Common source set.

MultiLoader Template This project provides a Gradle project template that can compile mods for both Forge and Fabric using a common sourceset. This pr

Jared 130 Jan 5, 2023
The common module is for the TenIO framework.

TenIO Common Module TenIO is an open-source project to create multiplayer online games that includes a java NIO (Non-blocking I/O) based server specif

Kong 1 Nov 24, 2021
This project contains many sample codes for demonstrating the usage of some common design patterns.

STUDY COMMON DESIGN PATTERNS 1. About this project This project contains many sample codes for demonstrating the usage of the following design pattern

Võ Trần Minh Quân 21 Jan 2, 2023
An example on how to build a configurable widget to trigger external searches along with Liferay search to Elasticsearch.

Liferay External Searches An example on how to build a configurable widget to trigger external searches along with Liferay search to Elasticsearch. Ge

Louis-Guillaume Durand 4 Oct 25, 2021
In this course, we will learn how to build a complete full-stack web application using Spring boot as backend and React (React Hooks) as frontend

In this course, we will learn how to build a complete full-stack web application using Spring boot as backend and React (React Hooks) as frontend. We will use MySQL database to store and retrieve the data.

Ramesh Fadatare 43 Dec 22, 2022
This is a Food Delivery Mobile Application. Build Using React Native

Ax Food Delivery Service This is a Food Delivery Mobile Application build using ?????????? ???????????? ?? Installation Clone this repository git clon

Mindula Dilthushan Manamperi 13 Jul 14, 2022
🏗 Build container images for your Java applications.

Jib ☑️ Jib User Survey What do you like best about Jib? What needs to be improved? Please tell us by taking a one-minute survey. Your responses will h

null 12.4k Jan 9, 2023
Build criterion and ecosystem above multi-model databases

ShardingSphere - Building a Criterion and Ecosystem Above Multi-Model Databases Official Website: https://shardingsphere.apache.org/ Stargazers Over T

The Apache Software Foundation 17.8k Jan 9, 2023