Support multiple JDKs during build #44

vy · 2020-01-21T08:45:46Z

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.

The text was updated successfully, but these errors were encountered:

giltene · 2020-01-21T14:53:31Z

+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 · 2020-01-22T15:12:13Z

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 · 2020-01-29T14:00:56Z

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 · 2020-01-29T14:01:27Z

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 · 2020-01-29T14:20:31Z

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 · 2020-02-27T07:52:26Z

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

TheMrMilchmann · 2020-05-27T12:28:01Z

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 · 2021-01-07T13:43:22Z

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 · 2021-01-07T13:53:21Z

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 · 2021-01-08T15:04:48Z

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.

nipafx · 2021-03-09T20:12:39Z

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.

bmarwell · 2021-04-09T06:17:12Z

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.

evpaassen · 2021-05-03T15:17:14Z

For the Gradle users, it would be incredibly useful if Gradle could auto-detect JVMs provisioned by the setup-java action using their Toolchains for JVM projects feature.

There's already an issue in the Gradle repository to make this happen, but it needs a way to detect the provisioned JVMs: gradle/gradle#14903. Perhaps a bit of guidance from the maintainers of this action could get things running?

bmarwell · 2021-06-01T04:17:54Z

Any update on this?

laeubi · 2021-08-04T09:42:38Z

The tycho project could use that as well...

Gradle will by default use the same JDK for building the project as it does for running Gradle. Newer JDKs are assumed to be more performant, contain fewer bugs and to come with desirable features that we would like to utilize in our build, but doing so should not endanger backwards compatibility for the plugin itself. We can do that now by utilizing Gradle toolchains, which allows us to use one JDK/JRE for running Gradle and the other for building the project, i.e. executing `javac`. Doing this requires us to make multiple JDKs available to the Gradle build action for each individual execution of the build. The setup-java action doesn't support this at the moment, and the multiple build steps configured for actions/setup-java in this commit is at best a workaround for this, and at worst a bad assumption with respect to no environment variables or other settings being overwritten. Also, there's no handling of duplicate invocations of the action with the end result being duplicate JDKs installed. Hopefully both actions/setup-java and gradle/gradle-build-action will handle this case gracefully. For more details, see: - actions/setup-java#44 - gradle/gradle#14903

This commit decouples the JDK running Gradle from the one building the project. Gradle will by default use the same JDK for building the project as it does for running Gradle. Newer JDKs are assumed to be more performant, contain fewer bugs and to come with desirable features that we would like to utilize in our build, but doing so should not endanger backwards compatibility for the plugin itself. We can do that now by utilizing Gradle toolchains, which allows us to use one JDK/JRE for running Gradle and the other for building the project, i.e. executing `javac`. Doing this requires us to make multiple JDKs available to the Gradle build action for each individual execution of the build. The setup-java action doesn't support this at the moment, and the multiple build steps configured for actions/setup-java in this commit is at best a workaround for this, and at worst a bad assumption with respect to environment variables or other settings being overwritten. Furthermore, there's no handling of duplicate invocations of the action. Hopefully both actions/setup-java and gradle/gradle-build-action will handle all of this gracefully. For more details, see: - actions/setup-java#44 - gradle/gradle#14903

laeubi · 2022-06-05T05:04:15Z

and configure in toolchains.xml

There is even a PR for this already, would be cool if it could be merged: #282

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

This sounds really useful do you think you can open a PR?

@dmitry-shibanov any chance this could be implemented soon or a PR being accepted for this?

e-korolevskii · 2022-06-09T18:05:43Z

Hello @laeubi,

We will explore this pull request and the possibility of adding this functionality.

dsame · 2022-07-05T21:33:09Z

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

vy · 2022-07-06T18:18:56Z

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.

laeubi · 2022-07-06T18:25:36Z

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

dsame · 2022-07-07T04:48:36Z

@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?

dsame · 2022-07-15T15:22:29Z

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

Okeanos · 2022-08-17T20:24:31Z

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.

nielsbasjes · 2022-09-04T10:15:44Z

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

dmitry-shibanov · 2022-09-09T12:54:38Z

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.

This commit decouples the JDK running Gradle from the one building the project. Gradle will by default use the same JDK for building the project as it does for running Gradle. Newer JDKs are assumed to be more performant, contain fewer bugs and to come with desirable features that we would like to utilize in our build, but doing so should not endanger backwards compatibility for the plugin itself. We can do that now by utilizing Gradle toolchains, which allows us to use one JDK/JRE for running Gradle and the other for building the project, i.e. executing `javac`. Doing this requires us to make multiple JDKs available to the Gradle build action for each individual execution of the build. The setup-java action doesn't support this at the moment, and the multiple build steps configured for actions/setup-java in this commit is at best a workaround for this, and at worst a bad assumption with respect to environment variables or other settings being overwritten. Furthermore, there's no handling of duplicate invocations of the action. Hopefully both actions/setup-java and gradle/gradle-build-action will handle all of this gracefully. For more details, see: - actions/setup-java#44 - gradle/gradle#14903

mprins mentioned this issue Jan 26, 2020

Setup maven workflow actions on gitub B3Partners/kadaster-gds2#47

Merged

joshmgross added the enhancement label Mar 6, 2020

tbroyer mentioned this issue May 24, 2020

Add output parameter with path to installed JDK #65

Closed

likern mentioned this issue Aug 3, 2020

core.getInput treats YAML booleans as strings actions/toolkit#361

Closed

TheMrMilchmann mentioned this issue Oct 13, 2020

[Feature request] settings.xml AdoptOpenJDK/install-jdk#11

Closed

dmitry-shibanov added the feature request New feature or request to improve the current logic label Jan 14, 2021

maxim-lobanov removed the enhancement label Feb 10, 2021

evpaassen mentioned this issue May 3, 2021

Detect JDKs provisioned by Github actions automatically gradle/gradle#14903

Closed

pmonks mentioned this issue Nov 8, 2021

Migrate from TravisCI to GitHub Actions pmonks/multigrep#9

Closed

rognan mentioned this issue Nov 28, 2021

Bump JDK running Gradle from 11 to 17 rognan/deno-gradle-plugin#9

Merged

Okeanos mentioned this issue Jan 13, 2022

Maven Toolchains Support #276

Closed

Okeanos mentioned this issue Jan 17, 2022

Add Maven Toolchains Declaration (#276) #282

Merged

2 tasks

zhongnansu mentioned this issue Feb 25, 2022

Change Default CI version to JDK 11 opensearch-project/reporting#290

Merged

6 tasks

jwillemsen mentioned this issue Jun 1, 2022

Extend github action CI testing JacORB/JacORB#316

Open

laeubi mentioned this issue Jun 4, 2022

Allow to define a JAVA_HOME variable for each installation #337

Closed

5 tasks

laeubi mentioned this issue Jun 5, 2022

Rework the handling of profiles eclipse-tycho/tycho#995

Merged

e-korolevskii self-assigned this Jun 7, 2022

e-korolevskii added the investigation The issue is under investigation label Jun 9, 2022

e-korolevskii removed their assignment Jul 4, 2022

dsame self-assigned this Jul 5, 2022

vy closed this as completed Jul 6, 2022

dsame mentioned this issue Jul 7, 2022

Add "Install multiple JDKs" README section #351

Merged

dsame reopened this Jul 7, 2022

dmitry-shibanov mentioned this issue Aug 18, 2022

Add support for multiple jdks #368

Merged

2 tasks

dmitry-shibanov self-assigned this Sep 9, 2022

dmitry-shibanov closed this as completed Sep 9, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support multiple JDKs during build #44

Support multiple JDKs during build #44

vy commented Jan 21, 2020

giltene commented Jan 21, 2020

jvalkeal commented Jan 22, 2020

mprins commented Jan 29, 2020

giltene commented Jan 29, 2020

mprins commented Jan 29, 2020

koppor commented Feb 27, 2020

TheMrMilchmann commented May 27, 2020

jonashackt commented Jan 7, 2021 •

edited

Loading

mprins commented Jan 7, 2021

jonashackt commented Jan 8, 2021

nipafx commented Mar 9, 2021

bmarwell commented Apr 9, 2021

evpaassen commented May 3, 2021

bmarwell commented Jun 1, 2021

laeubi commented Aug 4, 2021

laeubi commented Jun 5, 2022 •

edited

Loading

e-korolevskii commented Jun 9, 2022

dsame commented Jul 5, 2022 •

edited

Loading

vy commented Jul 6, 2022

laeubi commented Jul 6, 2022

dsame commented Jul 7, 2022

dsame commented Jul 15, 2022

Okeanos commented Aug 17, 2022

nielsbasjes commented Sep 4, 2022

dmitry-shibanov commented Sep 9, 2022

Support multiple JDKs during build #44

Support multiple JDKs during build #44

Comments

vy commented Jan 21, 2020

giltene commented Jan 21, 2020

jvalkeal commented Jan 22, 2020

mprins commented Jan 29, 2020

giltene commented Jan 29, 2020

mprins commented Jan 29, 2020

koppor commented Feb 27, 2020

TheMrMilchmann commented May 27, 2020

jonashackt commented Jan 7, 2021 • edited Loading

mprins commented Jan 7, 2021

jonashackt commented Jan 8, 2021

nipafx commented Mar 9, 2021

bmarwell commented Apr 9, 2021

evpaassen commented May 3, 2021

bmarwell commented Jun 1, 2021

laeubi commented Aug 4, 2021

laeubi commented Jun 5, 2022 • edited Loading

e-korolevskii commented Jun 9, 2022

dsame commented Jul 5, 2022 • edited Loading

vy commented Jul 6, 2022

laeubi commented Jul 6, 2022

dsame commented Jul 7, 2022

dsame commented Jul 15, 2022

Okeanos commented Aug 17, 2022

nielsbasjes commented Sep 4, 2022

dmitry-shibanov commented Sep 9, 2022

jonashackt commented Jan 7, 2021 •

edited

Loading

laeubi commented Jun 5, 2022 •

edited

Loading

dsame commented Jul 5, 2022 •

edited

Loading