Add actions/setup-java@v4.2.1

docs/adrs/0000-v2-setup-java.md

@@ -0,0 +1,65 @@
+# 0. V2 setup-java
+
+Date: 2020-08-24
+
+Status: Proposed
+
+# Context
+
+- The `v1` version of `setup-java` downloads and installs Zulu builds of OpenJDK. There is a huge ask from customers to offer AdoptOpenJDK/Adoptium builds of OpenJDK: https://github.com/actions/setup-java/issues/13
+
+- Zulu and AdoptOpenJDK aren't the only distributions of Java though. Other providers include Oracle OpenJDK or Amazon Corretto and ideally it would be nice to support downloading Java from all providers.
+
+- GitHub Actions virtual environments install and default to AdoptOpenJDK builds of OpenJDK. `setup-java` should give users an option to download and use other distributions that may not be be installed
+
+# Decision
+
+## New input
+
+A new required input parameter (titled `distribution`) will be added to `setup-java` that will allow users to specify the distribution that they would like to download
+
+```yaml
+  with:
+    java-version: '11'
+    distribution: adoptium
+```
+
+## Default Behavior
+
+There will be no default distribution that we pick for the user. Users will have to specify a distribution in their YAML or else the action will fail.
+
+Requiring a default version will break users that are pinned to `@main` as they will have no `distribution` specified in their YAML. Telemetry indicates that only a small percentage of users would be effected though. Users pinned to `v1` will be uneffected. This change is meant to not be backward compatible and it is acceptable to change the default behavior because a new major version will be released alongside these changes.
+
+## Extensibility & Documentation
+
+`setup-java` should be structured in such a way that will allow the open source community to easily add support for extra distributions.
+
+Existing code will be restructured so that distribution specific code will be easily separated. Currently the core download logic is in a single file, `installer.ts`. This file will be split up and abstracted out so that there will be no vendor specified logic. Each distribution will have it's own files under `src/distributions` that will contain the core setup logic for a specific distribution. 
+
+```yaml
+ ∟ src/
+    installer.ts # core installer logic
+    distributions/
+        ∟ adoptium/ # adoptium (formerly AdoptOpenJDK) specific logic
+        ∟ zulu/ # zulu specific logic
+        ∟ # future distributions will be added here 
+```
+
+The contribution doc (`CONTRIBUTING.md`) will describe how a new distribution should be added and how everything should be structured.
+
+## v2-preview
+
+There will be a `v2-preview` branch that will be created for development and testing. Any changes will first be merged into `v2-preview` branch. After a period of testing & verification, the `v2-preview` branch will be merged into the `main` branch and a `v2` tag will be created. Any [GitHub public documentation](https://docs.github.com/en/actions/language-and-framework-guides/github-actions-for-java) and [starter workflows](https://github.com/actions/starter-workflows) that mention `setup-java` will then be updated to use `v2` instead of `v1`.
+
+## Goals & Anti-Goals
+
+The main focus of the `v2` version of `setup-java` will be to add support for adoptium builds of openJDK in addition to Zulu builds of openJDK. In addition, extensibility will be a priority so that other distributions can be added in the future.
+
+The `setup-java` action has some logic that creates a `settings.xml` file so that it is easier to publish packages. Any improvements or modifications to this logic or anything Gradle/Maven specific will be avoided during the development of the `v2-preview`.
+
+# Consequences
+
+- Users will have more flexibility and the freedom to choose a specific distribution that they would like (AdoptOpenJDK builds of OpenJDK in addition or Zulu builds of OpenJDK)
+- `setup-java` will be structured in such a way that will allow for more distributions to be easily added in the future
+- A large subset of users pin to `@main` or `@master` instead of to a specific version (`v1`). By introducing a breaking change that now requires a distribution to be specified, many users will have their workflows fail until they go and update their yaml
+- Higher maintenance and support burden moving forward

docs/adrs/README.md

@@ -0,0 +1,19 @@
+# ADRs
+
+ADR, short for "Architecture Decision Record" is a way of capturing important architectural decisions, along with their context and consequences.
+
+This folder includes ADRs for the setup-java action. ADRs are proposed in the form of a pull request, and they commonly follow this format:
+
+* **Title**: short present tense imperative phrase, less than 50 characters, like a git commit message.
+
+* **Status**: proposed, accepted, rejected, deprecated, superseded, etc.
+
+* **Context**: what is the issue that we're seeing that is motivating this decision or change.
+
+* **Decision**: what is the change that we're actually proposing or doing.
+
+* **Consequences**: what becomes easier or more difficult to do because of this change.
+
+---
+
+- More information about ADRs can be found [here](https://github.com/joelparkerhenderson/architecture_decision_record).

docs/advanced-usage.md

@@ -0,0 +1,545 @@
+# Usage
+- [Selecting a Java distribution](#Selecting-a-Java-distribution)
+  - [Eclipse Temurin](#Eclipse-Temurin)
+  - [Adopt](#Adopt)
+  - [Zulu](#Zulu)
+  - [Liberica](#Liberica)
+  - [Microsoft](#Microsoft)
+  - [Amazon Corretto](#Amazon-Corretto)
+  - [Oracle](#Oracle)
+  - [Alibaba Dragonwell](#Alibaba-Dragonwell)
+- [Installing custom Java package type](#Installing-custom-Java-package-type)
+- [Installing custom Java architecture](#Installing-custom-Java-architecture)
+- [Installing custom Java distribution from local file](#Installing-Java-from-local-file)
+- [Testing against different Java distributions](#Testing-against-different-Java-distributions)
+- [Testing against different platforms](#Testing-against-different-platforms)
+- [Publishing using Apache Maven](#Publishing-using-Apache-Maven)
+- [Publishing using Gradle](#Publishing-using-Gradle)
+- [Hosted Tool Cache](#Hosted-Tool-Cache)
+- [Modifying Maven Toolchains](#Modifying-Maven-Toolchains)
+- [Java-version file](#Java-version-file)
+
+See [action.yml](../action.yml) for more details on task inputs.
+
+## Selecting a Java distribution
+Inputs `java-version` and `distribution` are mandatory and needs to be provided. See [Supported distributions](../README.md#Supported-distributions) for a list of available options.
+
+### Eclipse Temurin
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'temurin'
+    java-version: '21'
+- run: java -cp java HelloWorldApp
+```
+
+### Adopt
+**NOTE:** Adopt OpenJDK got moved to Eclipse Temurin and won't be updated anymore. It is highly recommended to migrate workflows from `adopt` to `temurin` to keep receiving software and security updates. See more details in the [Good-bye AdoptOpenJDK post](https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/).
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'adopt-hotspot'
+    java-version: '11'
+- run: java -cp java HelloWorldApp
+```
+
+### Zulu
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'zulu'
+    java-version: '21'
+    java-package: jdk # optional (jdk, jre, jdk+fx or jre+fx) - defaults to jdk
+- run: java -cp java HelloWorldApp
+```
+
+### Liberica
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'liberica'
+    java-version: '21'
+    java-package: jdk # optional (jdk, jre, jdk+fx or jre+fx) - defaults to jdk
+- run: java -cp java HelloWorldApp
+```
+
+### Microsoft
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'microsoft'
+    java-version: '21'
+- run: java -cp java HelloWorldApp
+```
+
+### Using Microsoft distribution on GHES
+
+`setup-java` comes pre-installed on the appliance with GHES if Actions is enabled. When dynamically downloading the Microsoft Build of OpenJDK distribution, `setup-java` makes a request to `actions/setup-java` to get available versions on github.com (outside of the appliance). These calls to `actions/setup-java` are made via unauthenticated requests, which are limited to [60 requests per hour per IP](https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting). If more requests are made within the time frame, then you will start to see rate-limit errors during downloading that looks like: `##[error]API rate limit exceeded for...`.
+
+To get a higher rate limit, you can [generate a personal access token on github.com](https://github.com/settings/tokens/new) and pass it as the `token` input for the action:
+
+```yaml
+uses: actions/setup-java@v4
+with:
+  token: ${{ secrets.GH_DOTCOM_TOKEN }}
+  distribution: 'microsoft'
+  java-version: '21'
+```
+
+If the runner is not able to access github.com, any Java versions requested during a workflow run must come from the runner's tool cache. See "[Setting up the tool cache on self-hosted runners without internet access](https://docs.github.com/en/enterprise-server@3.2/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access)" for more information.
+
+### Amazon Corretto
+**NOTE:** Amazon Corretto only supports the major version specification.
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'corretto'
+    java-version: '21'
+- run: java -cp java HelloWorldApp
+```
+
+### Oracle
+**NOTE:** Oracle Java SE Development Kit is only available for version 17 and later.
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'oracle'
+    java-version: '21'
+- run: java -cp java HelloWorldApp
+```
+
+### Alibaba Dragonwell
+**NOTE:** Alibaba Dragonwell only provides jdk.
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'dragonwell'
+    java-version: '8'
+- run: java -cp java HelloWorldApp
+```
+
+## Installing custom Java package type
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: '<distribution>'
+    java-version: '11'
+    java-package: jdk # optional (jdk or jre) - defaults to jdk
+- run: java -cp java HelloWorldApp
+```
+
+
+## Installing custom Java architecture
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: '<distribution>'
+    java-version: '11'
+    architecture: x86 # optional - default value derived from the runner machine
+- run: java -cp java HelloWorldApp
+```
+
+## Installing Java from local file
+If your use-case requires a custom distribution or a version that is not provided by setup-java, you can download it manually and setup-java will take care of the installation and caching on the VM:
+
+```yaml
+steps:
+- run: |
+    download_url="https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.10%2B9/OpenJDK11U-jdk_x64_linux_hotspot_11.0.10_9.tar.gz"
+    wget -O $RUNNER_TEMP/java_package.tar.gz $download_url
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'jdkfile'
+    jdkFile: ${{ runner.temp }}/java_package.tar.gz
+    java-version: '11.0.0'
+    architecture: x64
+    
+- run: java -cp java HelloWorldApp
+```
+
+If your use-case requires a custom distribution (in the example, alpine-linux is used) or a version that is not provided by setup-java and you want to always install the latest version during runtime, then you can use the following code to auto-download the latest JDK, determine the semver needed for setup-java, and setup-java will take care of the installation and caching on the VM:
+
+```yaml
+   steps:
+      - name: fetch latest temurin JDK
+        id: fetch_latest_jdk
+        run: |
+          major_version={{ env.JAVA_VERSION }} # Example 16 or 21 or 22
+          cd $RUNNER_TEMP
+          response=$(curl -s "https://api.github.com/repos/adoptium/temurin${major_version}-binaries/releases")
+          latest_jdk_download_url=$(echo "$response" | jq -r '.[0].assets[] | select(.name | contains("jdk_x64_alpine-linux") and endswith(".tar.gz")) | .browser_download_url')
+          curl -Ls "$latest_jdk_download_url" -o java_package.tar.gz
+          latest_jdk_json_url=$(jdk_download_url "$response" | jq -r '.[0].assets[] | select(.name | contains("jdk_x64_alpine-linux") and endswith(".tar.gz.json")) | .browser_download_url')
+          latest_semver_version=$(curl -sL $latest_jdk_json_url | jq -r 'version.semver')
+          echo "java_version=$latest_semver_version" >> "$GITHUB_OUTPUT"
+
+      - uses: actions/setup-java@v4
+        with:
+          distribution: 'jdkfile'
+          jdkFile: ${{ runner.temp }}/java_package.tar.gz
+          java-version: {{ steps.fetch_latest_jdk.outputs.java_version }}
+          architecture: x64
+       - run: java -cp java HelloWorldApp
+```
+
+## Testing against different Java distributions
+**NOTE:** The different distributors can provide discrepant list of available versions / supported configurations. Please refer to the official documentation to see the list of supported versions.
+```yaml
+jobs:
+  build:
+    runs-on: ubuntu-20.04
+    strategy:
+      matrix:
+        distribution: [ 'zulu', 'temurin' ]
+        java: [ '8', '11' ]
+    name: Java ${{ matrix.Java }} (${{ matrix.distribution }}) sample
+    steps:
+      - uses: actions/checkout@v4
+      - name: Setup java
+        uses: actions/setup-java@v4
+        with:
+          distribution: ${{ matrix.distribution }}
+          java-version: ${{ matrix.java }}
+      - run: java -cp java HelloWorldApp
+```
+
+#### Testing against different platforms
+```yaml
+jobs:
+  build:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        java: [ '8', '11' ]
+        os: [ 'ubuntu-latest', 'macos-latest', 'windows-latest' ]
+    name: Java ${{ matrix.Java }} (${{ matrix.os }}) sample
+    steps:
+      - uses: actions/checkout@v4
+      - name: Setup java
+        uses: actions/setup-java@v4
+        with:
+          distribution: 'temurin'
+          java-version: ${{ matrix.java }}
+      - run: java -cp java HelloWorldApp
+```
+
+## Publishing using Apache Maven
+### Yaml example:
+```yaml
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v4
+    - name: Set up JDK 11
+      uses: actions/setup-java@v4
+      with:
+        distribution: '<distribution>'
+        java-version: '11'
+
+    - name: Build with Maven
+      run: mvn -B package --file pom.xml
+
+    - name: Publish to GitHub Packages Apache Maven
+      run: mvn deploy
+      env:
+        GITHUB_TOKEN: ${{ github.token }} # GITHUB_TOKEN is the default env for the password
+
+    - name: Set up Apache Maven Central
+      uses: actions/setup-java@v4
+      with: # running setup-java again overwrites the settings.xml
+        distribution: 'temurin'
+        java-version: '11'
+        server-id: maven # Value of the distributionManagement/repository/id field of the pom.xml
+        server-username: MAVEN_USERNAME # env variable for username in deploy
+        server-password: MAVEN_CENTRAL_TOKEN # env variable for token in deploy
+        gpg-private-key: ${{ secrets.MAVEN_GPG_PRIVATE_KEY }} # Value of the GPG private key to import
+        gpg-passphrase: MAVEN_GPG_PASSPHRASE # env variable for GPG private key passphrase
+
+    - name: Publish to Apache Maven Central
+      run: mvn deploy
+      env:
+        MAVEN_USERNAME: maven_username123
+        MAVEN_CENTRAL_TOKEN: ${{ secrets.MAVEN_CENTRAL_TOKEN }}
+        MAVEN_GPG_PASSPHRASE: ${{ secrets.MAVEN_GPG_PASSPHRASE }}
+```
+
+The two `settings.xml` files created from the above example look like the following.
+
+`settings.xml` file created for the first deploy to GitHub Packages
+```xml
+<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
+  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
+  <servers>
+    <server>
+      <id>github</id>
+      <username>${env.GITHUB_ACTOR}</username>
+      <password>${env.GITHUB_TOKEN}</password>
+    </server>
+    <server>
+      <id>gpg.passphrase</id>
+      <passphrase>${env.GPG_PASSPHRASE}</passphrase>
+    </server>
+  </servers>
+</settings>
+```
+
+`settings.xml` file created for the second deploy to Apache Maven Central
+```xml
+<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
+  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
+  <servers>
+    <server>
+      <id>maven</id>
+      <username>${env.MAVEN_USERNAME}</username>
+      <password>${env.MAVEN_CENTRAL_TOKEN}</password>
+    </server>
+    <server>
+      <id>gpg.passphrase</id>
+      <passphrase>${env.MAVEN_GPG_PASSPHRASE}</passphrase>
+    </server>
+  </servers>
+</settings>
+```
+
+***NOTE***: The `settings.xml` file is created in the Actions `$HOME/.m2` directory. If you have an existing `settings.xml` file at that location, it will be overwritten. See [below](#apache-maven-with-a-settings-path) for using the `settings-path` to change your `settings.xml` file location.
+
+If you don't want to overwrite the `settings.xml` file, you can set `overwrite-settings: false`
+
+### Extra setup for pom.xml:
+
+The Maven GPG Plugin configuration in the pom.xml file should contain the following structure to avoid possible issues like `Inappropriate ioctl for device` or `gpg: signing failed: No such file or directory`:
+
+```xml
+<configuration>
+  <!-- Prevent gpg from using pinentry programs -->
+  <gpgArguments>
+    <arg>--pinentry-mode</arg>
+    <arg>loopback</arg>
+  </gpgArguments>
+</configuration>
+```
+GPG 2.1 requires `--pinentry-mode` to be set to `loopback` in order to pick up the `gpg.passphrase` value defined in Maven `settings.xml`.
+
+### GPG
+
+If `gpg-private-key` input is provided, the private key will be written to a file in the runner's temp directory, the private key file will be imported into the GPG keychain, and then the file will be promptly removed before proceeding with the rest of the setup process. A cleanup step will remove the imported private key from the GPG keychain after the job completes regardless of the job status. This ensures that the private key is no longer accessible on self-hosted runners and cannot "leak" between jobs (hosted runners are always clean instances).
+
+**GPG key should be exported by: `gpg --armor --export-secret-keys YOUR_ID`**
+
+See the help docs on [Publishing a Package](https://help.github.com/en/github/managing-packages-with-github-packages/configuring-apache-maven-for-use-with-github-packages#publishing-a-package) for more information on the `pom.xml` file.
+
+***NOTE***: If the error that states, `gpg: Sorry, no terminal at all requested - can't get input` [is encountered](https://github.com/actions/setup-java/issues/554), please update the version of `maven-gpg-plugin` to 1.6 or higher.
+
+## Apache Maven with a settings path
+
+When using an Actions self-hosted runner with multiple shared runners the default `$HOME` directory can be shared by a number runners at the same time which could overwrite existing settings file. Setting the `settings-path` variable allows you to choose a unique location for your settings file.
+
+```yaml
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v4
+    - name: Set up JDK 11 for Shared Runner
+      uses: actions/setup-java@v4
+      with:
+        distribution: '<distribution>'
+        java-version: '11'
+        server-id: github # Value of the distributionManagement/repository/id field of the pom.xml
+        settings-path: ${{ github.workspace }} # location for the settings.xml file
+
+    - name: Build with Maven
+      run: mvn -B package --file pom.xml
+
+    - name: Publish to GitHub Packages Apache Maven
+      run: mvn deploy -s $GITHUB_WORKSPACE/settings.xml
+      env:
+        GITHUB_TOKEN: ${{ github.token }}
+```
+
+## Publishing using Gradle
+```yaml
+jobs:
+
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v4
+
+    - name: Set up JDK 11
+      uses: actions/setup-java@v4
+      with:
+        distribution: '<distribution>'
+        java-version: '11'
+
+    - name: Build with Gradle
+      run: gradle build
+
+    - name: Publish to GitHub Packages
+      run: gradle publish
+      env:
+        USERNAME: ${{ github.actor }}
+        PASSWORD: ${{ secrets.GITHUB_TOKEN }}
+```
+
+***NOTE: The `USERNAME` and `PASSWORD` need to correspond to the credentials environment variables used in the publishing section of your `build.gradle`.***
+
+See the help docs on [Publishing a Package with Gradle](https://help.github.com/en/github/managing-packages-with-github-packages/configuring-gradle-for-use-with-github-packages#example-using-gradle-groovy-for-a-single-package-in-a-repository) for more information on the `build.gradle` configuration file.
+
+## Hosted Tool Cache
+GitHub Hosted Runners have a tool cache that comes with some Java versions pre-installed. This tool cache helps speed up runs and tool setup by not requiring any new downloads. There is an environment variable called `RUNNER_TOOL_CACHE` on each runner that describes the location of this tools cache and this is where you can find the pre-installed versions of Java. `setup-java` works by taking a specific version of Java in this tool cache and adding it to PATH if the version, architecture and distribution match.
+
+Currently, LTS versions of Eclipse Temurin (`temurin`) are cached on the GitHub Hosted Runners.
+
+The tools cache gets updated on a weekly basis. For information regarding locally cached versions of Java on GitHub hosted runners, check out [GitHub Actions Virtual Environments](https://github.com/actions/virtual-environments).
+
+## Modifying Maven Toolchains
+The `setup-java` action generates a basic [Maven Toolchains declaration](https://maven.apache.org/guides/mini/guide-using-toolchains.html) for specified Java versions by either creating a minimal toolchains file or extending an existing declaration with the additional JDKs.
+
+### Installing Multiple JDKs With Toolchains
+Subsequent calls to `setup-java` with distinct distribution and version parameters will continue to extend the toolchains declaration and make all specified Java versions available.
+
+```yaml
+steps:
+- uses: actions/setup-java@v4
+  with:
+    distribution: '<distribution>'
+    java-version: |
+      8
+      11
+
+- uses: actions/setup-java@v4
+  with:
+    distribution: '<distribution>'
+    java-version: '15'
+```
+
+The result is a Toolchain with entries for JDKs 8, 11 and 15. You can even combine this with custom JDKs of arbitrary versions:
+
+```yaml
+- run: |
+    download_url="https://example.com/java/jdk/6u45-b06/jdk-6u45-linux-x64.tar.gz"
+    wget -O $RUNNER_TEMP/java_package.tar.gz $download_url
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'jdkfile'
+    jdkFile: ${{ runner.temp }}/java_package.tar.gz
+    java-version: '1.6'
+    architecture: x64
+```
+
+This will generate a Toolchains entry with the following values: `version: 1.6`, `vendor: jdkfile`, `id: Oracle_1.6`.
+
+### Modifying The Toolchain Vendor For JDKs
+Each JDK provider will receive a default `vendor` using the `distribution` input value but this can be overridden with the `mvn-toolchain-vendor` parameter as follows.
+
+```yaml
+- run: |
+    download_url="https://example.com/java/jdk/6u45-b06/jdk-6u45-linux-x64.tar.gz"
+    wget -O $RUNNER_TEMP/java_package.tar.gz $download_url
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'jdkfile'
+    jdkFile: ${{ runner.temp }}/java_package.tar.gz
+    java-version: '1.6'
+    architecture: x64
+    mvn-toolchain-vendor: 'Oracle'
+```
+
+This will generate a Toolchains entry with the following values: `version: 1.6`, `vendor: Oracle`, `id: Oracle_1.6`.
+
+In case you install multiple versions of Java at once with multi-line `java-version` input setting the `mvn-toolchain-vendor` still only accepts one value and will use this value for installed JDKs as expected when installing multiple versions of the same `distribution`.
+
+```yaml
+steps:
+- uses: actions/setup-java@v4
+  with:
+    distribution: '<distribution>'
+    java-version: |
+      8
+      11
+    mvn-toolchain-vendor: Eclipse Temurin
+```
+
+### Modifying The Toolchain ID For JDKs
+Each JDK provider will receive a default `id` based on the combination of `distribution` and `java-version` in the format of `distribution_java-version` (e.g. `temurin_11`) but this can be overridden with the `mvn-toolchain-id` parameter as follows.
+
+```yaml
+steps:
+- uses: actions/checkout@v4
+- uses: actions/setup-java@v4
+  with:
+    distribution: 'temurin'
+    java-version: '11'
+    mvn-toolchain-id: 'some_other_id'
+- run: java -cp java HelloWorldApp
+```
+
+In case you install multiple versions of Java at once you can use the same syntax as used in `java-versions`. Please note that you have to declare an ID for all Java versions that will be installed or the `mvn-toolchain-id` instruction will be skipped wholesale due to mapping ambiguities.
+
+```yaml
+steps:
+- uses: actions/setup-java@v4
+  with:
+    distribution: '<distribution>'
+    java-version: |
+      8
+      11
+    mvn-toolchain-id: |
+      something_else
+      something_other
+```
+
+## Java version file
+If the `java-version-file` input is specified, the action will extract the version from the file and install it.
+
+Supported files are .java-version and .tool-versions.
+In .java-version file, only the version should be specified, e.g., 17.0.7.
+In .tool-versions file, java version should be preceded by the java keyword, e.g., java 17.0.7.
+.java-version recognizes all variants of the version description according to [jenv](https://github.com/jenv/jenv) and .tool-version recognizes all variants of the version description according to [asdf](https://github.com/asdf-vm/asdf).
+
+If both java-version and java-version-file inputs are provided, the java-version input will be used.
+
+Valid entry options:
+```
+major versions: 8, 11, 16, 17, 21
+more specific versions: 1.8.0.2, 17.0, 11.0, 11.0.4, 8.0.232, 8.0.282+8
+early access (EA) versions: 15-ea, 15.0.0-ea
+versions with specified distribution: openjdk64-11.0.2
+```
+If the file contains multiple versions, only the first one will be recognized.

docs/contributors.md

@@ -0,0 +1,114 @@
+# Contributors
+
+Thank you for contributing!
+
+We have prepared a short guide so that the process of making your contribution is as simple and clear as possible. Please check it out before you contribute!
+
+## How can I contribute...
+
+* [Contribute Documentation:green_book:](#contribute-documentation)
+
+* [Contribute Code :computer:](#contribute-code)
+
+* [Provide Support on Issues:pencil:](#provide-support-on-issues)
+
+* [Review Pull Requests:mag:](#review-pull-requests)
+
+## Contribute documentation
+
+Documentation is a super important, critical part of this project. Docs are how we keep track of what we're doing, how, and why. It's how we stay on the same page about our policies and how we tell others everything they need to be able to use this project or contribute to it. 
+
+Documentation contributions of any size are welcome! Feel free to contribute even if you're just rewording a sentence to be more clear, or fixing a spelling mistake!
+
+**How to contribute:**
+
+Pull requests are the easiest way to contribute changes to git repos at GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes.
+
+- Please check that no one else has already created a pull request with these or similar changes
+- Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request 
+- Make sure your changes are formatted properly and consistently with the rest of the documentation
+- Re-read what you wrote, and run a spellchecker on it to make sure you didn't miss anything
+- If your pull request is connected to an open issue, please, leave a link to this issue in the `Related issue:` section
+- If you later need to add new commits to the pull request, you can simply commit the changes to the local branch and then push them. The pull request gets automatically updated
+
+**Once you've filed the pull request:**
+
+- Maintainers will review your pull request
+- If a maintainer requests changes, first of all, try to think about this request critically and only after that implement and request another review
+- If your PR gets accepted, it will soon be merged into the main branch. But your contribution will take effect only after the release of a new version of the action and updating the major tag
+> Sometimes maintainers reject pull requests and that's ok! Usually, along with rejection, we supply the reason for it. Nonetheless, we still really appreciate you taking the time to do it, and we don't take that lightly :heart:
+
+## Contribute code
+
+We like code commits a lot! They're super handy, and they keep the project going and doing the work it needs to do to be useful to others.
+
+Code contributions of just about any size are acceptable!
+
+The main difference between code contributions and documentation contributions is that contributing code requires the inclusion of relevant tests for the code being added or changed. Contributions without accompanying tests will be held off until a test is added unless the maintainers consider the specific tests to be either impossible or way too much of a burden for such a contribution.
+
+**How to contribute:**
+
+Pull requests are the easiest way to contribute changes to git repos at GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes.
+
+- Please check that no one else has already created a pull request with these or similar changes
+- Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request
+- Make sure your changes are well formatted and that all tests are passing
+- If your pull request is connected to an open issue, please, leave a link to this issue in the `Related issue:` section
+- If you later need to add new commits to the pull request, you can simply commit the changes to the local branch and then push them. The pull request gets automatically updated
+
+**Learn more about how to work with the repository:**
+
+- To implement new features or fix bugs, you need to make changes to the `.ts` files, which are located in the `src` folder
+- To comply with the code style, **you need to run the `format` script**
+- To lint the code, **you need to run the `lint:fix` script**
+- To transpile source code to `javascript` we use [NCC](https://github.com/vercel/ncc). **It is very important to run the `build` script after making changes**, otherwise your changes will not get into the final `javascript` build
+
+**Learn more about how to implement tests:**
+
+Adding or changing tests is an integral part of making a change to the code. 
+Unit tests are in the `__tests__` folder, and end-to-end tests are in the `workflows` folder, particularly take a look at the files with `e2e` prefix, for instance, [e2e-cache.yml](https://github.com/actions/setup-java/blob/main/.github/workflows/e2e-cache.yml).
+
+- The contributor can add various types of tests (like unit tests or end-to-end tests), which, in his opinion, will be necessary and sufficient for testing new or changed functionality
+- Tests should cover a successful execution, as well as some edge cases and possible errors
+- As already mentioned, pull requests without tests will be considered more carefully by maintainers. If you are sure that in this situation the tests are not needed or cannot be implemented with a commensurate effort - please add this clarification message to your pull request
+
+**Once you've filed the pull request:**
+
+- CI will start automatically with some checks. Wait until the end of the execution and make sure that all checks passed successfully. If some checks fail, you can open them one by one, try to find the reason for failing and make changes to your code to resolve the problem
+- Maintainers will review your pull request
+- If a maintainer requests changes, first of all, try to think about his request critically and only after that implement and request another review
+- If your PR gets accepted, it will soon be merged into the main branch. But your contribution will take effect only after the release of a new version of the action and updating the major tag
+> Sometimes maintainers reject pull requests and that's ok! Usually, along with rejection, we supply the reason for it. Nonetheless, we still really appreciate you taking the time to do it, and we don't take that lightly :heart:
+
+## Provide support on issues
+
+Helping out other users with their questions is an awesome way of contributing to any community. It's not uncommon for most of the issues on open source projects to be support-related questions by users trying to understand something they ran into or find their way around a known bug.
+
+**To help other folks out with their questions:**
+
+- Go to the [issue tracker](https://github.com/actions/setup-java/issues)
+- Read through the list until you find something that you're familiar enough with to answer to
+- Respond to the issue with whatever details are needed to clarify the question, or get more details about what's going on
+- Once the discussion wraps up and things are clarified, ask the original issue filer (or a maintainer) to close it for you
+ 
+*Some notes on picking up support issues:*
+
+- Avoid responding to issues you don't know you can answer accurately
+- Try to refer to past issues with accepted answers as much as possible. Link to them from your replies
+- Be kind and patient with users. Often, folks who have run into confusing things might be upset or impatient. This is natural. If you feel uncomfortable in conversation with them, it's better to stay away or withdraw from the issue.
+
+ > If some user is violating our code of conduct [standards](https://github.com/actions/setup-java/blob/main/CODE_OF_CONDUCT.md#our-standards), refer to the [enforcement](https://github.com/actions/setup-java/blob/main/CODE_OF_CONDUCT.md#enforcement) section of the Code of Conduct to resolve the conflict
+ 
+
+## Review pull requests
+ 
+
+Another great way to contribute is is to review pull request. Please, be extra kind: people who submit code/doc contributions are putting themselves in a pretty vulnerable position, and have put time and care into what they've done (even if that's not obvious to you!) Please, always respond with respect, and be understanding, but don't feel like you need to sacrifice your standards for their sake, either.
+ 
+**How to review:**
+
+- Go to the [pull requests](https://github.com/actions/setup-java/pulls)
+- Make sure you're familiar with the code or documentation is updated, unless it's a minor change (spellchecking, minor formatting, etc.)
+- Review changes using the GitHub functionality. You can ask a clarifying question, point out an error or suggest an alternative. 
+> Note: You may ask for minor changes - "nitpicks", but consider whether they are real blockers to merging or not
+- Submit your review, which may include comments, an approval, or a changes request

docs/switching-to-v2.md

@@ -0,0 +1,35 @@
+# Switching to V2
+## Java distribution
+The major breaking change in V2 is the new mandatory `distribution` input. This field should be specified with one of supported distributions. See [Supported distributions](../README.md#Supported-distributions) for a list of available options.  
+Use the `zulu` keyword if you would like to continue using the same distribution as in V1.
+```yaml
+steps:
+- uses: actions/checkout@v2
+- uses: actions/setup-java@v2
+  with:
+    distribution: 'zulu'
+    java-version: '11'
+    java-package: jdk # optional (jdk or jre) - defaults to jdk
+- run: java -cp java HelloWorldApp
+```
+
+**General recommendation** — configure CI with the same distribution that is used on your local dev machine.
+
+## Installing custom Java distribution from local file
+Since the `distribution` input is required in V2, you should specify it using `jdkfile` to continue installing Java from a local file on the runner
+```yaml
+steps:
+- run: |
+    download_url="https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.10%2B9/OpenJDK11U-jdk_x64_linux_hotspot_11.0.10_9.tar.gz"
+    wget -O $RUNNER_TEMP/java_package.tar.gz $download_url
+- uses: actions/setup-java@v2
+  with:
+    distribution: 'jdkfile'
+    jdkFile: ${{ runner.temp }}/java_package.tar.gz
+    java-version: '11.0.0'
+    architecture: x64
+```
+
+## Dropping legacy Java version syntax 1.x
+V1 supported legacy Java syntax such as `1.8` (same as `8`) and `1.8.0.212` (same as `8.0.212`). 
+V2 dropped support for legacy syntax so workflows should be updated accordingly.