OpenLiberty
Dev mode should fail if JAVA_HOME is not set
When dev mode detects that JAVA_HOME is not set, it currently just prints out a warning. Instead, dev mode should fail and print out an error explaining that the user is required to set JAVA_HOME.
- Determine if it makes sense to require JAVA_HOME
- If JAVA_HOME should be required, give an error if it is not set
@ericglau @TrevCraw what do you think about maven-toolchains support? => https://maven.apache.org/guides/mini/guide-using-toolchains.html
This way the user could run the maven build with Java 17 and run Liberty on Java 8 and test on Java 21. Using tests with another JRE/JDK is already supported, same for the compiler plugin. I do not want to hijack this issue, but the appropriate title would probably be:
Dev mode should fail if neither JAVA_HOME nor toolchain is set
WDYT?
@bmarwell thanks for bringing this up.
I'm not sure about the original issue here. I'm not sure I see dev mode failing with JAVA_HOME not set, picking up java/javac from the PATH.
But I opened a new issue https://github.com/OpenLiberty/ci.maven/issues/1630 to track the toolchain support idea.
Can I ask...for my education.. what's an example of doing a java compile with one JDK and the test execution with another JDK? (I assume you mean the JVM forked by the failsafe plugin by default). I've only looked at simpler examples where Maven is run with one JDK and the java compile, etc. runs with a 2nd JDK. But your case involves possibly 3 JDKs even. Thank you.
While you can just raise the JDK level to 11 and still compile bytecode to 7 (even with 17 to 7!), there's demand by some to actually test this with a real Java 7/8 runtime. Tests might differ, e.g. due to the new DNS resolution, encoding and time/currency format differences, property files using UTF-8 (since Java 9), multi release JARs, and other things.
For example, even my Java 8 projects at work can only be compiled using Java 11, just because the --release switch is so much more convenient than using the animal sniffer plugin.
YMMV. 😉
While you can just raise the JDK level to 11 and still compile bytecode to 7 (even with 17 to 7!), there's demand by some to actually test this with a real Java 7/8 runtime.
@bmarwell thanks for trying to educate me here :) I do understand the general motivation for separating the JDK running Maven vs. the JDK running Liberty, but was trying to ask how far you needed to take this.
You listed as an example:
"the user could run the maven build with Java 17 and run Liberty on Java 8 and test on Java 21".
My first thought in how we'd support this in Liberty dev mode would be to simply extend our implementation to add support for the built-in "jdk" toolchain.
So, if I understand correctly (and I might not), this design would seem like it could easily allow for say, running Maven with Java 17 and then running the jdk-toolchain-enabled plugins with say Java 8. So if we extended the 'jdk' toolchain behavior in dev mode we could imagine Liberty too being run with Java 8 as well.
But you specifically went further than than and mentioned the example of testing on Java 21 in combination with Liberty Java 8 and mvn Java 17... so I just wanted to stop and ask what such a configuration would look like?
Are you thinking this is possible today via a custom toolchain https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/custom.html (which presumably dev mode would also support)? Or, if not, I'm just trying to get a sense of what this would look like... what can you do today outside of dev mode to provide something like this that we could extend dev mode to add support for?
Well, I don't need it. But support for this will come out of the box. I'm currently on mobile, but consider this:
JAVA_HOME points to Java 20-ea Maven is executed with 20-ea
Toolchains provide Java 17 for the compiler plugin, configured with --release=7 (or any other version).
surefire is configured with toolchains pointing to java 11
Failsafe is configured with toolchains pointing to a java 17.
Not sure that makes any sense, but the plugins I mentioned already support this.
This video of @khmarbaise shows this really well (just without the liberty plugin): https://youtu.be/-KbDcJcglPc
If there's some user request for this, I'd be happy to help. I just wouldn't do it if there's no demand.
OK, I get it now from looking at the YT video (thank you).
The part I was missing is that the plugin goals have their own 'jdkToolchain' parameter which can be configured., see:
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#jdkToolchain https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#jdkToolchain
which is how we could end up with more than two JDKs, but even three or more. I hadn't seen this yet in the toolchain doc.
So to answer my question, I think if we added support for just the jdk toolchain, whether set more globally and/or via individual plugin (noting dev mode can sometimes blur the distinction between configuring a plugin vs. configuring an execution of that plugin), we would probably meet the conceivable use cases. We would, it seems, not need to get into custom toolchains.
I will say this isn't the first time I've heard a request for this function, though I didn't see an open issue before today. If you are interested in helping, well, I should probably move this over to the other issue #1630 . Thanks for your offer, and thanks for your interest, and also thanks again for the example here.