Support multiple JDKs during build

[vy]

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.

[giltene]

+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.

[jvalkeal]

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'));

[mprins]

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

[giltene]

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

[mprins]

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

[koppor]

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

[TheMrMilchmann]

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.

[jonashackt]

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

[mprins]

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

[jonashackt]

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.