Support multiple JDKs during build

Certain projects might require multiple JDKs during build (e.g., Apache Log4j requires Java 7 and Java 9+ by means of toolchains.xml) and in its current form, that is not possible via setup-java.

+1

It appears to me that adding an optional java-home variable that would determine where to place the java package (which can currently be a jre, jdk, or jdk+fx), overriding the default location, would suffice, right? One would the use setup-java multiple times, once per version.

I'm just wondering what happens if you define two different setup-java steps with different jvm's. Looking sources it set's this extendedJavaHome env variable:

setup-java/src/installer.ts

Lines 76 to 79 in b52cd69

    
           let extendedJavaHome = 'JAVA_HOME_' + version + '_' + arch; 
        
           core.exportVariable('JAVA_HOME', toolPath); 
        
           core.exportVariable(extendedJavaHome, toolPath); 
        
           core.addPath(path.join(toolPath, 'bin'));

I managed to do this by calling out to the setup-java action for each JDK I have confgured in my toolchain (1.8 and 11) plus once for the JDK I want to run maven with (so 3 times in total).

see B3Partners/kadaster-gds2#47

I'm just wondering what happens if you define two different setup-java steps with different jvm's. Looking sources it set's this extendedJavaHome env variable:

I think that knowing where the JDK was installed is not enough. Some tools expect that java versions to appear at specific file paths. E.g. https://github.com/apache/logging-log4j2/blob/64a5c73636cef24c5cbb70143eef99536944d188/.travis-toolchains.xml#L28 . You could probably do something by symlinking the requested path to where extendedJavaHome points, but that would be messy for the user, and fairly easy for us to do in installer.ts if indicated by setting an optional java-home variable

Some tools expect that java versions to appear at specific file paths.

see:
https://github.com/B3Partners/kadaster-gds2/runs/415167771?check_suite_focus=true#step:7:14

 Inspect environment0s
JAVA_HOME_8_x64=/opt/hostedtoolcache/jdk/8.0.242/x64
Run set | grep JAVA
  set | grep JAVA
  shell: /bin/bash -e {0}
  env:
    JAVA_HOME: /opt/hostedtoolcache/jdk/8.0.242/x64
    JAVA_HOME_11.0.6_x64: /opt/hostedtoolcache/jdk/11.0.6/x64
    JAVA_HOME_8.0.242_x64: /opt/hostedtoolcache/jdk/8.0.242/x64
    JAVA_HOME_8_x64: /opt/hostedtoolcache/jdk/8.0.242/x64
    JAVA_HOME=/opt/hostedtoolcache/jdk/8.0.242/x64
    JAVA_HOME_11_X64=/usr/lib/jvm/zulu-11-azure-amd64
    JAVA_HOME_12_X64=/usr/lib/jvm/zulu-12-azure-amd64
    JAVA_HOME_7_X64=/usr/lib/jvm/zulu-7-azure-amd64
    JAVA_HOME_8_X64=/usr/lib/jvm/zulu-8-azure-amd64
    JAVA_HOME_8_x64=/opt/hostedtoolcache/jdk/8.0.242/x64

you can use environment vars in your toolchain

https://github.com/B3Partners/kadaster-gds2/blob/b0cd5c392bc1f48dec11c83c828254a868264467/.github/ubuntu-toolchains.xml#L6-L22

This somehow refs #21. Then, one can "just" rely on environment variables.

Hi, I forked this project a while ago to change some things according to my needs. However, there were also additional changes that might be of interest to this project. (Sorry for bringing them up so late. I could have sworn that I commented about this months ago.)

Supporting multiple JDKs was an important feature I needed at that time and the solution I ended up going with is adding an additional input parameter to the action used to specify the "target" environment variable/s with the following semantics:

If the target is not specified explicitly, only JAVA_HOME is set to point to the JDK.
If the target is specified explicitly, it is interpreted as a ; separated list of environment variables that will be set to point to the JDK. (JAVA_HOME is not set to point to the JDK unless the input explicitly contains JAVA_HOME.)

Naturally, this makes it incredibly easy to work with multiple JDK versions since their locations could simply be pointed to by separate environment variables. For example:

- uses: AdoptOpenJDK/install-jdk@v1
  with:
    version: '8'
- uses: AdoptOpenJDK/install-jdk@v1
  with:
    version: '9'
    targets: 'JDK_9'

This snippet suffices is sufficient to set up a Java 8 and Java 9 for parallel use. Here, 8 will be pointed to by JAVA_HOME, and 9 will be pointed to by JDK_9. (Also, note that this would also fix #21.)

Some tools expect that java versions to appear at specific file paths.

Additionally, should it become necessary to provide control about the directory in which the JDK should reside in (I have not seen the need arise yet), it would be possible to add this as an additional property. In my opinion, controlling the location of the file-system and the environment variables are orthogonal concepts that should not be configurable separately.

If you are interested I would love to get this integrated upstream and I would be happy to contribute.

I wonder if the matrix strategy is already everything we need here (as also stated on stackoverflow). I implemented this in codecentric/cxf-spring-boot-starter's action configuration in the .github/workflows/maven.yml:

name: github

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        java-version: [ 8, 11, 15 ]

    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-java@v1
      with:
        java-version: ${{ matrix.java-version }}
    - run: mvn -B install --no-transfer-progress --file pom.xml

steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
  with:
    java-version: ${{ matrix.java-version }}

No, this only installs 1 java version for one build, not multiple java versions for 1 build

Ah I see. Didn't get that first, maybe the issue could be refrased a bit like Support multiple JDKs during a single build step or similar.

Since Java 9, jlink can be used to create runtime images that are a subset of the full JDK (and hence OS-specific). For that, the tool needs an unzipped JDK lying around. The cool thing is that it can also create runtime images for a different OS than it is executed on, but then it of course needs that OS's JDK.

So it would be nice if setup-java could not only setup (and configure in toolchains.xml) different Java versions, but also JDKs for different operating systems.

Since Java 9, jlink can be used to create runtime images that are a subset of the full JDK (and hence OS-specific). For that, the tool needs an unzipped JDK lying around. The cool thing is that it can also create runtime images for a different OS than it is executed on, but then it of course needs that OS's JDK.

Look what we did for the maven-jlink-plugin:
https://github.com/apache/maven-jlink-plugin/blob/master/.github/workflows/maven.yml

While we could migrate to v2 and still use AdoptOpenJDK/install-jdk@v1 for the secondary java, it would be nice to have this as an out-of-the-box experience.

@vy

hello @vy, i believe the solution suggested by @jvalkeal do exactly that was requested:

    - uses: actions/setup-java@v1
      with:
        java-version: 8
    
    - uses: actions/setup-java@v1
      with:
        java-version: 11
    
    - uses: actions/setup-java@v1
      with:
        java-version: 15

installs all 3 JDKs in their own directory under /opt/hostedtoolcache/jdk.

And in case if it is needed to know the exact location of every JDK just store them somewhere, say in environment :

    - uses: actions/setup-java@v1
    with:
      java-version: 8
  - run: echo "JAVA_8=$JAVA_HOME" >> $GITHUB_ENV
  
  - uses: actions/setup-java@v1
    with:
      java-version: 11
  - run: echo "JAVA_11=$JAVA_HOME" >> $GITHUB_ENV
  
  - uses: actions/setup-java@v1
    with:
      java-version: 15
  - run: echo "JAVA_15=$JAVA_HOME" >> $GITHUB_ENV

the result is

#set|grep JAVA
JAVA_[1](https://github.com/akv-demo/setup-java-test/runs/7204409652?check_suite_focus=true#step:9:1)1=/opt/hostedtoolcache/jdk/11.0.[15](https://github.com/akv-demo/setup-java-test/runs/7204409652?check_suite_focus=true#step:9:16)/x64
JAVA_15=/opt/hostedtoolcache/jdk/15.0.7/x64
JAVA_8=/opt/hostedtoolcache/jdk/8.0.332/x64
JAVA_HOME=/opt/hostedtoolcache/jdk/15.0.7/x64
JAVA_HOME_11_0_15_X64=/opt/hostedtoolcache/jdk/11.0.15/x64
JAVA_HOME_11_X64=/usr/lib/jvm/temurin-11-jdk-amd64
JAVA_HOME_15_0_7_X64=/opt/hostedtoolcache/jdk/15.0.7/x64
JAVA_HOME_[17](https://github.com/akv-demo/setup-java-test/runs/7204409652?check_suite_focus=true#step:9:18)_X64=/usr/lib/jvm/temurin-17-jdk-amd64
JAVA_HOME_8_0_332_X64=/opt/hostedtoolcache/jdk/8.0.332/x64
JAVA_HOME_8_X64=/usr/lib/jvm/temurin-8-jdk-amd64

and

#ls  /opt/hostedtoolcache/jdk/
11.0.15
15.0.7
8.0.332

i think this approach is more straightforward than complicating the action with non-obvious inputs

Agreed that the concern expressed at the beginning can be addressed by running the action multiple times with different Java versions. As a matter of fact, that is what we ended up doing in Log4j too.

@vy

@vy if this is really the solution for this issue, it should mention the snippet on the Help/Readme page, I think this is not that obvious to the usual user.

@laeubi

@laeubi thank you for the suggestion, can you please take a look at this PR and confirm it is enough to clarify the use case?

The snippet to install multiple JDKs and keep the paths to each in the intermediate variables added to README by the PR #351

@laeubi

I am currently working on #276 (see #282 as already mentioned by @laeubi), i.e. directly supporting a generation of the toolchains.xml file mentioned in the initial issue comment. The changes are currently being reviewed and do the following things:

(optionally) generate a toolchains.xml into the default location, i.e. ~/.m2/toolchains.xml, or {{settings-path}}/toolchains.xml if the input value is specified in the setup-java step
add a toolchain with vendor, version, jdkHome, and (custom or default) id for the specified JDK
update any existing toolchains.xml in the specified path to add additional JDKs to it without removing existing entries

Checkout the aforementioned issue and PR for more details or in case you want to leave feedback; specifically before the maintainers decide the implementation is integration-worthy.

FYI: I have managed to make this work for my own project like this: https://github.com/nielsbasjes/yauaa/blob/main/.github/workflows/build.yml#L43

Hello everyone. We released a new version of setup-java with support of multiple jdks. For now I'm going to close the issue. If you have any concerns feel free to ping us.

Bump JDK running Gradle from 11 to 17

Navigation Menu

Repository navigation

Support multiple JDKs during build #44

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	let extendedJavaHome = 'JAVA_HOME_' + version + '_' + arch;
	core.exportVariable('JAVA_HOME', toolPath);
	core.exportVariable(extendedJavaHome, toolPath);
	core.addPath(path.join(toolPath, 'bin'));

Support multiple JDKs during build #44

Description

Activity

giltene commented on Jan 21, 2020

jvalkeal commented on Jan 22, 2020

mprins commented on Jan 29, 2020

giltene commented on Jan 29, 2020

mprins commented on Jan 29, 2020

koppor commented on Feb 27, 2020

TheMrMilchmann commented on May 27, 2020

jonashackt commented on Jan 7, 2021

mprins commented on Jan 7, 2021

jonashackt commented on Jan 8, 2021

nipafx commented on Mar 9, 2021

bmarwell commented on Apr 9, 2021

12 remaining items

dsame commented on Jul 5, 2022

vy commented on Jul 6, 2022

laeubi commented on Jul 6, 2022

dsame commented on Jul 7, 2022

dsame commented on Jul 15, 2022

Okeanos commented on Aug 17, 2022

nielsbasjes commented on Sep 4, 2022

dmitry-shibanov commented on Sep 9, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions