[jira] [Commented] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9

["Jeremy Landis (Jira)" <ji...@apache.org>]

    [ 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)