From 12c9e94f3733f8b528b6f51c954da6fcc637e152 Mon Sep 17 00:00:00 2001 From: Wen Zhou Date: Thu, 2 Jun 2022 14:23:50 +0200 Subject: [PATCH] docs: Update reference from "Adopt" to "Adoptium" (#2938) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * docs: Update reference from "Adopt" to "Adoptium" * docs: fix linter in md file * docs: fix more linter and disable terminology linter - ignore: Incorrect usage of the term: “png”, use “PNG” instead - ignore: ncorrect usage of the term: “website”, use “site” instead - ignore: Incorrect usage of the term: “html”, use “HTML” instead - fix typo * Update CHANGELOG.md Co-authored-by: Shelley Lambert Co-authored-by: Shelley Lambert --- CHANGELOG.md | 15 ++++---- README.md | 15 ++++---- RELEASING.md | 35 ++++++++++--------- build-farm/make-adopt-build-farm.sh | 6 ++-- .../platform-specific-configurations/aix.sh | 2 +- .../platform-specific-configurations/linux.sh | 2 +- .../platform-specific-configurations/mac.sh | 2 +- .../windows.sh | 2 +- .../set-platform-specific-configurations.sh | 6 ++-- configureBuild.sh | 2 +- docker-build.sh | 4 +-- makejdk-any-platform.1 | 2 +- makejdk-any-platform.sh | 6 ++-- native-build.sh | 2 +- sbin/common/common.sh | 4 +-- sbin/common/config_init.sh | 2 +- sbin/prepareWorkspace.sh | 4 +-- 17 files changed, 58 insertions(+), 53 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 93e6de1e4..81ee2a512 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,4 @@ + # Changelog for openjdk-build scripts (DEPRECATED) ## DEPRECATION NOTES @@ -44,7 +45,7 @@ can be generated manually as well. 1. `-bv` is removed, (long form `--variant` changes to `--build-variant`). 1. `-c` (long form `--clean-docker-build`) added to build from a clean docker container. 1. `-ca` changes to `-C`, (long form `--configure-args` stays the same). -1. `--clean-git-repos`, added to clean out any 'bad' local git repo you already have. +1. `--clean-git-repos`, added to clean out any 'bad' local git repository you already have. 1. `-D` (long form `--docker`) added for building in a docker container. 1. `-dsgc` is removed, (long form `--disable-shallow-git-clone` stays the same). 1. `-ftd` changes to `-f`, (long form `--freetype-dir` stays the same). @@ -52,7 +53,7 @@ can be generated manually as well. 1. `--freetype-version`, specify the version of freetype you are building. 1. `-h` (long form `--help`) added. 1. `-i` (long form `--ignore-container`) added to ignore existing docker container. -1. `-j, --jtreg` and `-js, --jtreg-subsets` are removed as tests should be run via the openjdk-tests repo / project. +1. `-j, --jtreg` and `-js, --jtreg-subsets` are removed as tests should be run via the aqa-tests repository / project. 1. `-J` (long form `--jdk-boot-dir` added to set JDK boot dir. 1. `-nc` (long form `--no-colour`) is removed. 1. `-p` (long form `--processors`) added to set number of processors in docker build. @@ -82,7 +83,7 @@ container. 1. `--sudo` added to run the docker container as root. 1. _docker-build.sh_ added. This script is invoked for building (Adopt) OpenJDK binaries in a Docker container. -1. _docker/jdk/x86_64/ubuntu/Dockerfile_ updated for various bug fixes. +1. _docker/jdk/x86_64/ubuntu/Dockerfile_ updated for various bugfixes. 1. _docker/jdk/x86_64/ubuntu/dockerConfiguration.sh_ files added. These contain Docker specific environment variables that the build scripts need (as opposed to falsely picking up the underlying native env). @@ -90,19 +91,19 @@ opposed to falsely picking up the underlying native env). ### Build Farm Support 1. New _build-farm/make-adopt-build-farm.sh_ added for the new AdoptOpenJDK -Build Farm jenkins pipeline to build Adopt OpenJDK binaries. Sets the default +Build Farm jenkins pipeline to build Adoptium OpenJDK binaries. Sets the default environment variables that are currently set in individual jobs. This allows us to now track and version these variables. 1. New _build-farm/set-platform-specific-configurations.sh_ added for the new -AdoptOpenJDK Build Farm jenkins pipeline to build Adopt OpenJDK binaries. Sets +AdoptOpenJDK Build Farm jenkins pipeline to build Adoptium OpenJDK binaries. Sets the default environment variables that are currently set in individual jobs. This allows us to now track and version these variables. 1. New _build-farm/platform-specific-configurations/.sh added for -the new AdoptOpenJDK Build Farm jenkins pipeline to build Adopt OpenJDK binaries. +the new AdoptOpenJDK Build Farm jenkins pipeline to build Adoptium OpenJDK binaries. Sets the default environment variables for specific platforms that are currently set in individual jobs. This allows us to now track and version these variables. 1. New _build-farm/sign-releases.sh added for the new AdoptOpenJDK Build Farm -jenkins pipeline to code sign Adopt OpenJDK binaries (Mac and Windows for now). +jenkins pipeline to code sign Adoptium OpenJDK binaries (Mac and Windows for now). 1. _pipelines/build/common/build_base_file.groovy_ added. This co-ordinates the various pipeline builds. 1._pipelines/build/common/create\_job\_from\_template.groovy_ added. This dynamically diff --git a/README.md b/README.md index d2414d022..5fde3ce60 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,4 @@ + # 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 . Those binaries are then made available for consumption at and via the API . @@ -6,7 +7,7 @@ These scripts can be used to build OpenJDK anywhere but are primarily used by Ec ## Where can I find the release status of Eclipse Temurin™ binaries? -Go to the [Eclipse Adoptium Top Level Project Repo](https://www.github.com/adoptium/adoptium/issues) for release tracking. +Go to the [Eclipse Adoptium Top Level Project repository](https://www.github.com/adoptium/adoptium/issues) for release tracking. ## TL;DR: I want to build a JDK NOW @@ -57,7 +58,7 @@ 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. +build jobs used for building Adoptium OpenJDK binaries. 1. The `docker` folder contains tools for generating dockerfiles which can be used as part of building OpenJDK inside a Docker container. 1. The `git-hg` folder has now been moved to it's own separate repository. See [openjdk-mirror-scripts](https://github.com/adoptium/mirror-scripts). @@ -72,7 +73,7 @@ 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. +`makejdk-any-platform.sh` is the entry point for building (Adoptium) 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 @@ -127,7 +128,7 @@ 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. +clean out any 'bad' local git repository you already have. --create-debug-image create a debug-image archive with the debug symbols. @@ -274,7 +275,7 @@ general preparation. ### Building OpenJDK from a non-Adoptium repository -These scripts default to using Adoptium as the OpenJDK source repo to build +These scripts default to using Adoptium as the OpenJDK source repository 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. @@ -334,7 +335,7 @@ Alongside the built assets a metadata file will be created with info about the b The Metadata class is contained in the [Metadata.groovy](https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/library/src/common/MetaData.groovy) file and the Json is constructed and written in the [openjdk_build_pipeline.groovy](https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/build/common/openjdk_build_pipeline.groovy) file. -It is worth noting the additional tags on the semver is the adopt build number. +It is worth noting the additional tags on the SemVer is the build number. Below are all of the keys contained in the metadata file and some example values that can be present. @@ -428,7 +429,7 @@ 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**. +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.` diff --git a/RELEASING.md b/RELEASING.md index 0f06479b2..951bb106e 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -1,3 +1,4 @@ + # Temurin Release Guide Don't be scared off by this document! If you already understand the stuff in the glossary section and are only working on a HotSpot release, then skip to [Steps for every version](#steps-for-every-version) later on. @@ -25,7 +26,7 @@ Don't be scared off by this document! If you already understand the stuff in th
Eclipse OpenJ9/OMR releases -### NOTE: Temurin does not ship OpenJ9 releases so this section has been collapsed as it it not required by anyone performing the Temurin release process +### NOTE1: Temurin does not ship OpenJ9 releases so this section has been collapsed as it it not required by anyone performing the Temurin release process - The OpenJ9 releases are based on three codebases - https://github.com/eclipse-openj9/openj9-omr (a platform abstraction layer which OpenJ9 builds use, based on https://github.com/eclipse/omr) @@ -44,6 +45,7 @@ Don't be scared off by this document! If you already understand the stuff in th - In the run up to the JDK GA date, the extensions team's OpenJDK auto-merge and acceptance jobs merge any new jdk builds into the `openj9-staging` and `openj9` branches, but NOT the `openj9-0.nn.0` release branch. - When it comes to the GA date, the auto-merged GA jdk "tag" needs to be merged into the `openj9-0.nn.0` release branch by the extensions team. - The release branch is also updated to pull in the GA Eclipse OpenJ9 & OMR release tags, and then the GA JDK binary is built. +
## OpenJDK Quarterly/New Release Process @@ -59,7 +61,7 @@ Don't be scared off by this document! If you already understand the stuff in th
Extra OpenJ9 prerequisite steps (skip for a Temurin HotSpot release) -### NOTE: Temurin does not ship OpenJ9 releases so this section has been collapsed as it it not required by anyone performing the Temurin release process +### NOTE2: Temurin does not ship OpenJ9 releases so this section has been collapsed as it it not required by anyone performing the Temurin release process 1. The extensions release branch (e.g. `openj9-0.17.0`) will exist from doing the milestone builds (OpenJ9 milestone process is covered in a later section). 2. Ask the extensions team to run their release-specific merge jobs to ensure they are up to date - this is not done by jobs at Adoptium. @@ -100,6 +102,7 @@ Don't be scared off by this document! If you already understand the stuff in th J9JDK_EXT_VERSION       := 11.0.5.0 # J9JDK_EXT_VERSION       := HEAD   <==  !!! Comment out this line ``` +
## Lockdown period @@ -108,7 +111,6 @@ During the week before release we lock down the `openjdk-build` and `ci-jenkins- only include "critical" fixes (i.e. those which will otherwise cause a build break or other problem which will prevent shipping the release builds. This stops last minute changes going in which may destabilise things. - If a change has to go in during this "lockdown" period it should be done by posting a comment saying "Requesting approval to merge during the lockdown period. Please thumbs up the comment to approve". If two committers into the @@ -127,7 +129,7 @@ Here are the steps: - `targetConfigurations`: remove all the entries for the variants you don't want to build (e.g. remove the openj9 ones for hotspot releases) or any platforms you don't want to release (Currently that would include OpenJ9 aarch64) - `releaseType: Release` -
Extra steps for OpenJ9 ONLY - For OpenJ9 releases, `overridePublishName` should be set to the github binaries publish name (NOTE: If you are doing a point release, do NOT adjust this as we don't want the filenames to include the `.x` part), e.g. `jdk8u232-b09_openj9-0.14.0` or `jdk-11.0.5+10_openj9-0.14.0`. Similarly, `scmReference` for OpenJ9 releases should be the name of the extensions release branch: e.g. `openj9-0.14.0`
+ For OpenJ9 releases, `overridePublishName` should be set to the GitHub binaries publish name (NOTE: If you are doing a point release, do NOT adjust this as we don't want the filenames to include the `.x` part), e.g. `jdk8u232-b09_openj9-0.14.0` or `jdk-11.0.5+10_openj9-0.14.0`. Similarly, `scmReference` for OpenJ9 releases should be the name of the extensions release branch: e.g. `openj9-0.14.0` - `adoptBuildNumber`: Leave blank unless you are doing a point release in which case it should be a number starting at `1` for the first point release. - `additionalConfigureArgs`: JDK8 automatically adds`--with-milestone=fcs` in `build.sh` so there's no need to provide it here. For JDK11+ use `--without-version-pre --without-version-opt` (for EA releases use: `--with-version-pre=ea --without-version-opt`) - `scmReference`: One of the following: @@ -144,14 +146,14 @@ Here are the steps: - Find the milestone build row, and click the "Grid" link - Check all tests are "Green", and if not "hover" over the icon and follow the Jenkins link to triage the errors... - Raise issues either at: - - [temurin-build](https://github.com/adoptium/temurin-build) or [openjdk-tests](https://github.com/AdoptOpenJDK/openjdk-tests) (for Adopt build or test issues) + - [temurin-build](https://github.com/adoptium/temurin-build) or [openjdk-tests](https://github.com/AdoptOpenJDK/openjdk-tests) (for Adoptium build or test issues) - [ci-jenkins-pipelines](https://github.com/adoptium/ci-jenkins-pipelines) (for jenkins pipelines specific issues) - [eclipse/openj9](https://github.com/eclipse-openj9/openj9) (for OpenJ9 issues) 1. Discuss failing tests with [Shelley Lambert](https://github.com/smlambert) 1. Once all AQA tests on all platforms have been signed off, then nightly tests can be re-enabled. See the notes on checking the regeneration job worked in step 1. 1. If "good to publish", then get permission to publish the release from the Adoptium PMC members, discussion is via the Adoptium [#release](https://adoptium.slack.com/messages/CLCFNV2JG) Slack channel. -1. Once permission has been obtained, run the [openjdk_release_tool](https://ci.adoptopenjdk.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/) to publish the releases to github (restricted access - if you can't see this link, you don't have access). It is *strongly recommended* that you run first with the `DRY_RUN` checkbox enabled and check the output to verify that the correct list of files you expected are picked up. - - `TAG`: (github binaries published name)  e.g. `jdk-11.0.5+9` or `jdk-11.0.5+9_openj9-0.nn.0` for OpenJ9 releases. If doing a point release, add that into the name e.g. for a `.3` release use something like these (NOTE that for OpenJ9 the point number goes before the openj9 version): `jdk8u232-b09.3` or `jdk-11.0.4+11.3_openj9-0.15.1` +1. Once permission has been obtained, run the [openjdk_release_tool](https://ci.adoptopenjdk.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/) to publish the releases to GitHub (restricted access - if you can't see this link, you don't have access). It is *strongly recommended* that you run first with the `DRY_RUN` checkbox enabled and check the output to verify that the correct list of files you expected are picked up. + - `TAG`: (GitHub binaries published name)  e.g. `jdk-11.0.5+9` or `jdk-11.0.5+9_openj9-0.nn.0` for OpenJ9 releases. If doing a point release, add that into the name e.g. for a `.3` release use something like these (NOTE that for OpenJ9 the point number goes before the openj9 version): `jdk8u232-b09.3` or `jdk-11.0.4+11.3_openj9-0.15.1` - `VERSION`: (select version e.g. `jdk11`) - `UPSTREAM_JOB_NAME`: (build-scripts/openjdkNN-pipeline) - `UPSTREAM_JOB_NUMBER`: (the job number of the build pipeline under build-scripts/openjdkNN-pipeline) e.g. 86 @@ -216,13 +218,14 @@ The following examples all use `-m1` as an example - this gets replaced with a l 5. Build and Test the OpenJDK for OpenJ9 "release" at Adoptium using a "Weekly" releaseType so it runs the extended tests. Submit the Build pipeline job as follows https://ci.adoptopenjdk.net/job/build-scripts/job/openjdkNN-pipeline/build?delay=0sec - `targetConfigurations`: remove all "hotspot" entries - `releaseType`: `Weekly` - - `overridePublishName`: github binaries publish name, e.g. `jdk8u232-b09_openj9-0.17.0-m1` or `jdk-11.0.5+10_openj9-0.17.0-m1` + - `overridePublishName`: GitHub binaries publish name, e.g. `jdk8u232-b09_openj9-0.17.0-m1` or `jdk-11.0.5+10_openj9-0.17.0-m1` (Note: Everything before the underscore should be copied from the OPENJDK_TAG value inside /closed/openjdk-tag.gmk) - `scmReference`: extensions release branch: e.g. `openj9-0.17.0` - `additionalConfigureArgs`: JDK8 automatically adds`--with-milestone=fcs` in `build.sh` so there's no need to provide it here. JDK11+: `--without-version-pre --without-version-opt` (for EA releases use: `--with-version-pre=ea --without-version-opt`) - `enableTests`: "ticked" - SUBMIT!! 6. Triage the results and publish as required with using the publish name from `overridePublishName` in the previous step but with `RELEASE` UNCHECKED as this is not a full release build. + ### OpenJDK "New" Major Release process @@ -243,7 +246,7 @@ The following examples all use `-m1` as an example - this gets replaced with a l - Add build scripts for the new JDK release. Example for [JDK 14](https://github.com/adoptium/temurin-build/commit/808b08fe2aefc005cf53f6cc1deb28a9b323ff) - Regenerate build jobs: - Create a New Item in the folder linked above that copies the `pipeline_jobs_generator_jdk` job. Call it `pipeline_jobs_generator_jdk`. - - Change the `Script Path` setting of the new job to `pipelines/build/regeneration/jdk_regeneration_pipeline.groovy`. Don't worry if this currently doesn't exist in this repo, you'll add it in step 3. + - Change the `Script Path` setting of the new job to `pipelines/build/regeneration/jdk_regeneration_pipeline.groovy`. Don't worry if this currently doesn't exist in this repository, you'll add it in step 3. - Update the `Script Path` setting of the JDK-HEAD job (`pipeline_jobs_generator_jdk`) to whatever the new JDK HEAD is. I.e. if the new head is JDK16, change `Script Path` to `pipelines/build/regeneration/jdk16_regeneration_pipeline.groovy` - If you are REMOVING a JDK version: - Delete the job `pipeline_jobs_generator_jdk` @@ -251,7 +254,7 @@ The following examples all use `-m1` as an example - this gets replaced with a l 1. Create the new build configurations for the release - https://github.com/adoptium/ci-jenkins-pipelines/tree/master/pipelines/jobs/configurations: - Create a new `jdk_pipeline_config.groovy` file with the desired `buildConfigurations` for the new pipeline. 99% of the time, copy and pasting the configs from the previous version is acceptable. Ensure that the classname and instance of it is changed to `Config`. Don't remove any old version configs. - - Furthermore, you will also need to create another config file to state what jobs will be run with any new versions. If it doesn't currently exist, add a `jdkxx.groovy` file to [configurations/](https://github.com/adoptium/ci-jenkins-pipelines/tree/master/pipelines/jobs/configurations). [Example on how to do this](https://github.com/adoptium/temurin-build/pull/1815/files). Note, some files will need to be named `jdkxxu.groovy` depending on whether the version is maintained in an update repo or not. These will be the ONLY os/archs/variants that are regenerated using the job regenerators as described in the [regeneration readme](https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/build/regeneration/README.md). + - Furthermore, you will also need to create another config file to state what jobs will be run with any new versions. If it doesn't currently exist, add a `jdkxx.groovy` file to [configurations/](https://github.com/adoptium/ci-jenkins-pipelines/tree/master/pipelines/jobs/configurations). [Example on how to do this](https://github.com/adoptium/temurin-build/pull/1815/files). Note, some files will need to be named `jdkxxu.groovy` depending on whether the version is maintained in an update repository or not. These will be the ONLY os/archs/variants that are regenerated using the job regenerators as described in the [regeneration readme](https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/build/regeneration/README.md). 1. Create a new Regeneration Pipeline for the downstream jobs - https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/build/regeneration: @@ -267,19 +270,19 @@ At some point in a java version's lifecycle, the JDK version will be maintained - [jdk-dev](https://mail.openjdk.java.net/mailman/listinfo/jdk-dev) - [jdk-updates-dev](https://mail.openjdk.java.net/mailman/listinfo/jdk-updates-dev) -When this occurs, usually a TSC member will create the `jdku` update repo ([example of the JDK11u one](https://github.com/adopium/openjdk-jdk11u)) via our Skara mirroring jobs that pull in the commit and tag info from the Mercurial repository. To find out more about Skara and our other mirroring jobs, see https://github.com/adoptium/mirror-scripts. +When this occurs, usually a TSC member will create the `jdku` update repository ([example of the JDK11u one](https://github.com/adopium/openjdk-jdk11u)) via our Skara mirroring jobs that pull in the commit and tag info from the Mercurial repository. To find out more about Skara and our other mirroring jobs, see https://github.com/adoptium/mirror-scripts. -*New Adopt mirror repo creation, by an Adoptium github Admin:* +*New Adoptium mirror repository creation, by an Adoptium GitHub Admin:* -1. Create a new empty repo adoptium/openjdk-jdkNNu +1. Create a new empty repository adoptium/openjdk-jdkNNu 2. Rename mirror job from https://ci.adoptopenjdk.net/view/git-mirrors/job/git-mirrors/job/git-skara-jdkNN to https://ci.adoptopenjdk.net/view/git-mirrors/job/git-mirrors/job/git-skara-jdkNNu 3. Update mirror job "Execute shell" to pass jdkNNu as parameter to bash ./skaraMirror.sh jdkNNu -4. Run the renamed job twice, first one will fail due to empty repo, 2nd run should succeed. +4. Run the renamed job twice, first one will fail due to empty repository, 2nd run should succeed. 5. Add the Adoptium.md "marker" text file to both branches "dev" and "release". -When the repo has been created, a few changes to the codebase will be necessary where the code references a jdk version but not it's new update version. I.e. `jdk11` became `jdk11u` when it was moved to an update repository. +When the repository has been created, a few changes to the codebase will be necessary where the code references a jdk version but not it's new update version. I.e. `jdk11` became `jdk11u` when it was moved to an update repository. -*If a product is to be moved to an update repo, follow these steps in chronological order to ensure our builds continue to function:* +*If a product is to be moved to an update repository, follow these steps in chronological order to ensure our builds continue to function:* 1. ci-jenkins-pipelines: Update the [configurations](https://github.com/adoptium/ci-jenkins-pipelines/tree/master/pipelines/jobs/configurations) Rename the nightly build targets file (it will be named `jdkxx.groovy`, [example here](https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/jobs/configurations/jdk15u.groovy)) to be `jdkxxu.groovy`. Do the same for the pipeline config file (named `jdkxx_pipeline_config.groovy`, [example here](https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/jobs/configurations/jdk15u_pipeline_config.groovy)). diff --git a/build-farm/make-adopt-build-farm.sh b/build-farm/make-adopt-build-farm.sh index d7fcac16a..ae3d98c61 100755 --- a/build-farm/make-adopt-build-farm.sh +++ b/build-farm/make-adopt-build-farm.sh @@ -94,8 +94,8 @@ then retryMax=5 until [ "$retryCount" -ge "$retryMax" ] do - # Use Adopt API to get the JDK Head number - echo "This appears to be JDK Head. Querying the Adopt API to get the JDK HEAD Number (https://api.adoptium.net/v3/info/available_releases)..." + # Use Adoptium API to get the JDK Head number + echo "This appears to be JDK Head. Querying the Adoptium API to get the JDK HEAD Number (https://api.adoptium.net/v3/info/available_releases)..." JAVA_FEATURE_VERSION=$(curl -q https://api.adoptium.net/v3/info/available_releases | awk '/tip_version/{print$2}') # Checks the api request was successful and the return value is a number @@ -112,7 +112,7 @@ then # Fail build if we still can't find the head number if [ -z "${JAVA_FEATURE_VERSION}" ] || ! [[ "${JAVA_FEATURE_VERSION}" -gt 0 ]] then - echo "Failed ${retryCount} times to query or parse the adopt api. Dumping headers via curl -v https://api.adoptium.net/v3/info/available_releases and exiting..." + echo "Failed ${retryCount} times to query or parse the Adoptium api. Dumping headers via curl -v https://api.adoptium.net/v3/info/available_releases and exiting..." curl -v https://api.adoptium.net/v3/info/available_releases echo curl returned RC $? in make_adopt_build_farm.sh exit 1 diff --git a/build-farm/platform-specific-configurations/aix.sh b/build-farm/platform-specific-configurations/aix.sh index 12bd023f5..640ffaabf 100755 --- a/build-farm/platform-specific-configurations/aix.sh +++ b/build-farm/platform-specific-configurations/aix.sh @@ -70,7 +70,7 @@ if [ ! -d "$(eval echo "\$$BOOT_JDK_VARIABLE")" ]; then echo "Could not use ${BOOT_JDK_VARIABLE} - using /usr/java${JDK_BOOT_VERSION}_64" # shellcheck disable=SC2140 export "${BOOT_JDK_VARIABLE}"="/usr/java${JDK_BOOT_VERSION}_64" - elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adopt has no build pre-8 + elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adoptium has no build pre-8 mkdir -p "${bootDir}" releaseType="ga" apiUrlTemplate="https://api.adoptium.net/v3/binary/latest/\${JDK_BOOT_VERSION}/\${releaseType}/aix/\${ARCHITECTURE}/jdk/hotspot/normal/adoptium" diff --git a/build-farm/platform-specific-configurations/linux.sh b/build-farm/platform-specific-configurations/linux.sh index 7dd0071c4..132926efb 100755 --- a/build-farm/platform-specific-configurations/linux.sh +++ b/build-farm/platform-specific-configurations/linux.sh @@ -142,7 +142,7 @@ if [ ! -d "$(eval echo "\$$BOOT_JDK_VARIABLE")" ]; then echo "Could not use ${BOOT_JDK_VARIABLE} - using /usr/lib/jvm/jdk-${JDK_BOOT_VERSION}" # shellcheck disable=SC2140 export "${BOOT_JDK_VARIABLE}"="/usr/lib/jvm/jdk-${JDK_BOOT_VERSION}" - elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adopt has no build pre-8 + elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adoptium has no build pre-8 mkdir -p "$bootDir" releaseType="ga" vendor="adoptium" diff --git a/build-farm/platform-specific-configurations/mac.sh b/build-farm/platform-specific-configurations/mac.sh index 19e3cfbc2..c8e0e583e 100755 --- a/build-farm/platform-specific-configurations/mac.sh +++ b/build-farm/platform-specific-configurations/mac.sh @@ -83,7 +83,7 @@ if [ ! -d "$(eval echo "\$$BOOT_JDK_VARIABLE")" ]; then if [ -x "/Library/Java/JavaVirtualMachines/jdk-${JDK_BOOT_VERSION}/Contents/Home/bin/javac" ]; then echo "Could not use ${BOOT_JDK_VARIABLE} - using /Library/Java/JavaVirtualMachines/jdk-${JDK_BOOT_VERSION}/Contents/Home" export "${BOOT_JDK_VARIABLE}"="/Library/Java/JavaVirtualMachines/jdk-${JDK_BOOT_VERSION}/Contents/Home" - elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adopt has no build pre-8 + elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adoptium has no build pre-8 mkdir -p "$bootDir" releaseType="ga" vendor="adoptium" diff --git a/build-farm/platform-specific-configurations/windows.sh b/build-farm/platform-specific-configurations/windows.sh index ec6682903..7dafec0ee 100755 --- a/build-farm/platform-specific-configurations/windows.sh +++ b/build-farm/platform-specific-configurations/windows.sh @@ -44,7 +44,7 @@ if [ ! -d "$(eval echo "\$$BOOT_JDK_VARIABLE")" ]; then echo "Could not use ${BOOT_JDK_VARIABLE} - using /cygdrive/c/openjdk/jdk-${JDK_BOOT_VERSION}" # shellcheck disable=SC2140 export "${BOOT_JDK_VARIABLE}"="/cygdrive/c/openjdk/jdk-${JDK_BOOT_VERSION}" - elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adopt has no build pre-8 + elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adoptium has no build pre-8 # This is needed to convert x86-32 to x32 which is what the API uses export downloadArch case "$ARCHITECTURE" in diff --git a/build-farm/set-platform-specific-configurations.sh b/build-farm/set-platform-specific-configurations.sh index a50e79a64..1eafa032c 100755 --- a/build-farm/set-platform-specific-configurations.sh +++ b/build-farm/set-platform-specific-configurations.sh @@ -98,13 +98,13 @@ then if [ $ret -ne 0 ] || [[ ! $fileContents =~ $contentsErrorRegex ]] then - # If there is no user platform config, use adopt's as a default instead - echo "[WARNING] Failed to download a user platform configuration file. Downloading Adopt's ${OPERATING_SYSTEM}.sh configuration file instead." + # If there is no user platform config, use Adoptium's as a default instead + echo "[WARNING] Failed to download a user platform configuration file. Downloading Adoptium's ${OPERATING_SYSTEM}.sh configuration file instead." downloadPlatformConfigFile "${ADOPT_PLATFORM_CONFIG_LOCATION}" "${OPERATING_SYSTEM}.sh" if [ $ret -ne 0 ] || [[ ! $fileContents =~ $contentsErrorRegex ]] then - echo "[ERROR] Failed to download a platform configuration file from User and Adopt's repositories" + echo "[ERROR] Failed to download a platform configuration file from User and Adoptium's repositories" exit 2 fi fi diff --git a/configureBuild.sh b/configureBuild.sh index 7d0f1a195..1d11e7f67 100755 --- a/configureBuild.sh +++ b/configureBuild.sh @@ -18,7 +18,7 @@ ################################################################################ # -# This script sets up the initial configuration for an (Adopt) OpenJDK Build. +# This script sets up the initial configuration for an Adoptium OpenJDK Build. # See the configure_build function and its child functions for details. # It's sourced by the makejdk-any-platform.sh script. # diff --git a/docker-build.sh b/docker-build.sh index d7e6932a9..195426ca5 100755 --- a/docker-build.sh +++ b/docker-build.sh @@ -16,7 +16,7 @@ ################################################################################ # -# This script deals with the configuration to build (Adopt) OpenJDK in a docker +# This script deals with the configuration to build (Adoptium) OpenJDK in a docker # container. # It's sourced by the makejdk-any-platform.sh script. # @@ -69,7 +69,7 @@ buildDockerContainer() ${BUILD_CONFIG[DOCKER]} build -t "${BUILD_CONFIG[CONTAINER_NAME]}" -f "${dockerFile}" . --build-arg "OPENJDK_CORE_VERSION=${BUILD_CONFIG[OPENJDK_CORE_VERSION]}" --build-arg "HostUID=${UID}" } -# Execute the (Adopt) OpenJDK build inside the Docker Container +# Execute the (Adoptium) OpenJDK build inside the Docker Container buildOpenJDKViaDocker() { diff --git a/makejdk-any-platform.1 b/makejdk-any-platform.1 index 1f7133e5e..66e3d4592 100755 --- a/makejdk-any-platform.1 +++ b/makejdk-any-platform.1 @@ -5,7 +5,7 @@ makejdk-any-platform.sh .SH SYNOPSIS "./makejdk-any-platform.sh [options] version" .SH DESCRIPTION -This script is the entry point for building (Adopt) OpenJDK binaries. Building +This script is the entry point for building (Adoptium) 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. diff --git a/makejdk-any-platform.sh b/makejdk-any-platform.sh index a89cadaa7..fc7e49cb2 100755 --- a/makejdk-any-platform.sh +++ b/makejdk-any-platform.sh @@ -19,7 +19,7 @@ ################################################################################ # -# Entry point to build (Adopt) OpenJDK binaries for any platform. +# Entry point to build (Adoptium) OpenJDK binaries for any platform. # # 1. Source scripts to support configuration, docker builds and native builds. # 2. Parse the Command Line Args @@ -47,7 +47,7 @@ source "${SCRIPT_DIR}/native-build.sh" # shellcheck source=configureBuild.sh source "${SCRIPT_DIR}/configureBuild.sh" -echo "Starting $0 to configure, build (Adopt)OpenJDK binary" +echo "Starting $0 to configure, build (Adoptium)OpenJDK binary" # Configure the build, display the parameters and write the config to disk # see ${SCRIPT_DIR}/sbin/common/config_init.sh for details @@ -57,7 +57,7 @@ writeConfigToFile # Store params to this script as "buildinfo" echo "$@" > ./workspace/config/makejdk-any-platform.args -# Let's build and test the (Adopt) OpenJDK binary in Docker or natively +# Let's build and test the (Adoptium) OpenJDK binary in Docker or natively if [ "${BUILD_CONFIG[USE_DOCKER]}" == "true" ] ; then buildOpenJDKViaDocker else diff --git a/native-build.sh b/native-build.sh index cac32550b..30c46bf4c 100755 --- a/native-build.sh +++ b/native-build.sh @@ -16,7 +16,7 @@ ################################################################################ # -# This script deals with the configuration to build (Adopt) OpenJDK natively. +# This script deals with the configuration to build (Adoptium) OpenJDK natively. # It's sourced by the makejdk-any-platform.sh script. # ################################################################################ diff --git a/sbin/common/common.sh b/sbin/common/common.sh index c61e622ca..a531c3649 100755 --- a/sbin/common/common.sh +++ b/sbin/common/common.sh @@ -41,8 +41,8 @@ function setOpenJdkVersion() { retryMax=5 until [ "$retryCount" -ge "$retryMax" ] do - # Use Adopt API to get the JDK Head number - echo "This appears to be JDK Head. Querying the Adopt API to get the JDK HEAD Number (https://api.adoptium.net/v3/info/available_releases)..." + # Use Adoptium API to get the JDK Head number + echo "This appears to be JDK Head. Querying the Adoptium API to get the JDK HEAD Number (https://api.adoptium.net/v3/info/available_releases)..." local featureNumber=$(curl -q https://api.adoptium.net/v3/info/available_releases | awk '/tip_version/{print$2}') # Checks the api request was successful and the return value is a number diff --git a/sbin/common/config_init.sh b/sbin/common/config_init.sh index 36516765d..96d2dd216 100755 --- a/sbin/common/config_init.sh +++ b/sbin/common/config_init.sh @@ -569,7 +569,7 @@ function configDefaults() { BUILD_CONFIG[CROSSCOMPILE]=false - # By default assume we have adopt patches applied to the repo + # By default assume we have Adoptium patches applied to the repo BUILD_CONFIG[ADOPT_PATCHES]=true BUILD_CONFIG[DISABLE_ADOPT_BRANCH_SAFETY]=false diff --git a/sbin/prepareWorkspace.sh b/sbin/prepareWorkspace.sh index 1bda1e05c..09940502c 100644 --- a/sbin/prepareWorkspace.sh +++ b/sbin/prepareWorkspace.sh @@ -17,7 +17,7 @@ ################################################################################ # -# This script prepares the workspace to build (Adopt) OpenJDK. +# This script prepares the workspace to build (Adoptium) OpenJDK. # See the configureWorkspace function for details # It is sourced by build.sh # @@ -102,7 +102,7 @@ checkoutAndCloneOpenJDKGitRepo() { fi if [[ "${BUILD_CONFIG[BUILD_VARIANT]}" == "${BUILD_VARIANT_TEMURIN}" ]]; then - # Verify Adopt patches tag is being built, otherwise we may be accidently just building "raw" OpenJDK + # Verify Adoptium patches tag is being built, otherwise we may be accidently just building "raw" OpenJDK if [ ! -f "${TEMURIN_MARKER_FILE}" ] && [ "${BUILD_CONFIG[DISABLE_ADOPT_BRANCH_SAFETY]}" == "false" ]; then echo "${TEMURIN_MARKER_FILE} marker file not found in fetched source to be built, this may mean the wrong SCMReference build parameter has been specified. Ensure the correct Temurin patch release tag is specified, eg.for build jdk-11.0.4+10, it would be jdk-11.0.4+10_adopt" exit 1