[
https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068335#comment-17068335
]
Jeremy Landis commented on MCOMPILER-339:
-----------------------------------------
I don't think this is a duplicate. This is a design issue. What is is asking
is to stop giving java the 'release' option if we are not compiling with java 9
or better. If using jdk 8 to run a build which maven should know, don't
provide the release option to java. It's just going to fail. This is making
it hard for us to have super poms that work in reasonable way. We have to set
other variables first, then try to get things working latest. It's extremely
complicated. Th rule of thumb is this, if I configured 'release' or
'testRelease', and the jdk being used to build is not jdk 9 or better, don't
give that parameter to java. Just issue a warning if you must.
For reference, my use case, I have a super pom that supports 400+ repos and
supports from java 7 through java 15 EA. It runs with java 8 at lowest level
using cross compilation. My super pom, I cannot just deside that 'release' is
not to be set as a property. I have to have many profiles and set some dummy
value first then later set the real value. It's not very clear like the old
ones were and causes a lot of friction.
The best rule of thumb here is simply don't pass java options it doesn't
support even if users misconfigure. I can assure you, like the reporter here,
I have not misconfigured. We are stuck due to a glitch in what is being done
now. The only way around it is to write extra properties that daisy chain
together which makes it more complicated on the setup. These are pretty
advanced and I'm sure the reporters is as well. I've personally been meaning
to report this for some time but just now doing so. So I'm glad I'm not alone.
But it is not an ask to translate anything. It's simple to ignore the
'release' / 'testRelease' if not intended for that jdk no matter the other
settings. That is all...
What reporter is doing is that he is getting stuck with a parent pom that
defined that variable. You cannot undo that portion. I was able to but it is
not pretty. Yes he is incorrectly setting 8 there, but really it shold just be
ignored, its wrong, its not applicable to jdk 8 thus it should not be provided
to the jdk to process.
> Skip --release flag if compilerVersion is lower than 1.9
> --------------------------------------------------------
>
> Key: MCOMPILER-339
> URL: https://issues.apache.org/jira/browse/MCOMPILER-339
> Project: Maven Compiler Plugin
> Issue Type: Improvement
> Affects Versions: 3.7.0
> Reporter: David J. M. Karlsen
> Priority: Major
>
> usecase: I have a build which is jdk10 by default, declared via the
> parent-pom.
> However, one submodule must be compiled and run with java8. I had hoped to
> get this working, by setting:
> {noformat}
> <properties>
> <maven.compiler.release>8</maven.compiler.release>
> <maven.compiler.source>1.8</maven.compiler.source>
> <maven.compiler.target>1.8</maven.compiler.target>
> <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
> </properties>
> {noformat}
>
> but it will fail with
> {noformat}
> Caused by: java.lang.IllegalArgumentException: invalid flag:
> --release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions
> (JavacTool.java:206)*11:53:45* at
> com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)*11:53:45*
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)*11:53:45*
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)*11:53:45*
> at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess
> (JavaxToolsCompiler.java:125)*11:53:45* at
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
> (JavacCompiler.java:174)*11:53:45* at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1075)*11:53:45* at
> org.apache.maven.plugin.compiler.TestCompilerMojo.execute
> (TestCompilerMojo.java:176)*11:53:45* at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)*11:53:45* at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)*11:53:45* at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:200)*11:53:45* at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:196)*11:53:45* at
> java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at
> java.util.concurrent.Executors$RunnableAdapter.call
> (Executors.java:511)*11:53:45* at java.util.concurrent.FutureTask.run
> (FutureTask.java:266)*11:53:45* at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1149)*11:53:45* at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:624)*11:53:45* at java.lang.Thread.run
> (Thread.java:748)
> {noformat}
> If the release flag could only be enabled for compiler versions supporting it
> it would be easier to juggle the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
