Closed vy closed 1 year ago
+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:
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).
I'm just wondering what happens if you define two different
setup-java
steps with different jvm's. Looking sources it set's thisextendedJavaHome
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
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:
JAVA_HOME
is set to point to the JDK.;
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.
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?
Any update on this?
The tycho project could use that as well...
and configure in
toolchains.xml
There is even a PR for this already, would be cool if it could be merged: https://github.com/actions/setup-java/pull/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?
Hello @laeubi,
We will explore this pull request and the possibility of adding this functionality.
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
#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 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 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 https://github.com/actions/setup-java/pull/351
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:
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
stepvendor
, version
, jdkHome
, and (custom or default) id
for the specified JDKtoolchains.xml
in the specified path to add additional JDKs to it without removing existing entriesCheckout 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.
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
.