[
https://issues.apache.org/jira/browse/NETBEANS-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467728#comment-17467728
]
Thomas Schapitz commented on NETBEANS-4595:
-------------------------------------------
Only remotely. Just like Netbeans, Maven on itself offers the possibility, to
use a JDK for compiling, testing, running, javadoc etc, that is different from
the one, that is used for executing Maven itself.
The same thing holds true for the relationship between Netbeans and Maven. You
may run Maven from within Netbeans with a different JDK, as the one Netbeans is
using for itself. This is what you can influence from within Netbeans.
But in your case it is even more complicated, because you are using the exec
plugin, which isn't even originally Apache Maven, but a remainder of the
Codehaus legacy (Codehaus is defunct since 2016). It has found a shelter here
[https://www.mojohaus.org/exec-maven-plugin/index.html]. So the bad news is:
Even if you configure Netbeans to use JDK 14 for execution, which will by
default, result in Maven using JDK 14 in compile, test-compile, javadoc and
test with surefire/failsafe - this will *not* happen for exec:exec. It *would*
happen, if you used the other goal offered by the exec plugin: exec:java,
which, alas, has another drawback: exec:java executes within the same process
as Maven itself, which might compromise the build.
I see the following options to remedy this:
* Try to get rid of the exec plugin all together. The example you uploaded
doesn't give away the reason, why you are using it. But most projects I
encountered so far, did well using surefire and/or failsafe to execute unit and
integration tests. If you are building a web app, or a spring boot service,
take a look at the spring boot plugin or the tomcat & jetty plugins. For next
to all java based tools, there is a dedicated plugin, so there is rarely a need
to use the exec plugin.
If this isn't an option, and you have to insist using the exec plugin:
* Use something like{{{}{}}}
{code:java}
<configuration>
<executable>${java.home}/bin/java</executable>
</configuration>{code}
${java.home} will refer to the home of the JDK used to execute Maven
* Use toolchains. The Documentation of toolchains explicitly mentions the exec
plugin as supported.
* accept the risks that result from using exec:java instead of exec:exec
> exec-maven-plugin Java version different from maven-compiler-plugin Java
> version in NetBeans project
> ----------------------------------------------------------------------------------------------------
>
> Key: NETBEANS-4595
> URL: https://issues.apache.org/jira/browse/NETBEANS-4595
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
> Affects Versions: 12.0, 12.4
> Environment: Windows 7, Ubuntu 20.04
> Reporter: Bernard
> Priority: Critical
> Attachments: testcase.zip
>
>
> I start up the NetBeans IDE 12.0 with a system environment JAVA_HOME (1.8)
> lower than what the IDE uses (14).
> In the project properties, I have set the Build|Compile|Java Platform to JDK
> 14 (Default) as expected.
> The IDE output window of Maven execution seems to show that the project is
> run with JAVA_HOME for JDK 14, running project files this way.
> But the exec-maven-plugin fails with java.lang.UnsupportedClassVersionError:
> com/mycompany/Start has been compiled by a more recent version of the Java
> Runtime (class file version 55.0), this version of the Java Runtime only
> recognizes class file versions up to 52.0
> This seems to indicate that the the exec-maven plugin runs under 1.8 in the
> IDE, ignoring the IDE's own override setting of JAVA_HOME of 14. It appears
> to use the JDK as set in JAVA_HOME, because if I set JAVA_HOME to 14.0 before
> IDE startup then it works.
> I am looking for the correct way, the right places, to set the JDK for any
> project specifically, regardless of the JAVA_HOME setting that is active when
> the IDE starts.
> My case can be reproduced by running the IDE 12.0 with JDK 14.0 installed,
> but with JAVA_HOME set to 1.8. before IDE startup. I use the Maven project
> generated from the command at https://wicket.apache.org/start/quickstart.html
> - all set to defaults. The file to run is Start.java.
> This is important to me because I must open many different projects with
> different JDKs so it is not practical to re-start the IDE with different
> JAVA_HOME settings each time. As it is, it appears that my setting is poorly
> defined - I must be missing something.
> I know that there are potentially other solutions in maven like the
> Toolchains plugin. However, with all of that, I would lose IDE support which
> is letting the project properties dialog drive the JDK in use for everything.
> Plus I can already see that the IDE aims to do the right thing by overriding
> JAVA_HOME - for some reason this does not seem to be working and I think that
> this might be the bug.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
