Repository navigation
Support multiple JDKs during build #44
Description
Activity
+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-javasteps with different jvm's. Looking sources it set's thisextendedJavaHomeenv variable:Lines 76 to 79 in b52cd69
I managed to do this by calling out to the
setup-javaaction 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).Reacted by Justin Kaeser, Beth Cimini and Bruno BorgesI'm just wondering what happens if you define two different
setup-javasteps with different jvm's. Looking sources it set's thisextendedJavaHomeenv 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:14Inspect 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/x64you can use environment vars in your toolchain
Reacted by Tim Perry and Johannes SchüthHi, 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_HOMEis 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_HOMEis not set to point to the JDK unless the input explicitly containsJAVA_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 byJDK_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.
Reacted by Sean Gilligan and Benjamin Marwell- If the target is not specified explicitly, only
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.xmlsteps: - 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
Reacted by Daniel Kraus, Ned Loynd, Hugo Manrique, Manu Sridharan and Brice DutheilAh I see. Didn't get that first, maybe the issue could be refrased a bit like
Support multiple JDKs during a single build stepor similar.Reacted by Remko PopmaSince Java 9,
jlinkcan 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.Reacted by Gunnar Morling and Daniel KrausSince Java 9,
jlinkcan 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.ymlWhile we could migrate to v2 and still use
AdoptOpenJDK/install-jdk@v1for the secondary java, it would be nice to have this as an out-of-the-box experience.12 remaining items
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: 15installs 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#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-amd64and
#ls /opt/hostedtoolcache/jdk/ 11.0.15 15.0.7 8.0.332i 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.
Reacted by Matthew ReadI am currently working on #276 (see #282 as already mentioned by @laeubi), i.e. directly supporting a generation of the
toolchains.xmlfile mentioned in the initial issue comment. The changes are currently being reviewed and do the following things:- (optionally) generate a
toolchains.xmlinto the default location, i.e.~/.m2/toolchains.xml, or{{settings-path}}/toolchains.xmlif the input value is specified in thesetup-javastep - add a toolchain with
vendor,version,jdkHome, and (custom or default)idfor the specified JDK - update any existing
toolchains.xmlin 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.
- (optionally) generate a
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
Reacted by Daniel KrausHello 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.
Reacted by Matthew Read- added 2 commits that reference this issue
on Sep 17, 2022
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 viasetup-java.