Ho do I run Proguard with JDK 10 / JDK 11 and setup maven plugin?
Migration issues concerning OpenJDK 11 & OpenJFX 11 (& Proguard)
First of all, Proguard 6.0.3 does not run on Java 11 yet
(#188 Support Java 11, see https://sourceforge.net/p/proguard/feature-requests/188/).
Your sources can be compiled with JDK 11. For proguard plugin we have to use JDK 10.
In maven-compiler-plugin, set version to JDK 10:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<source>10</source>
<target>10</target>
<compilerArgs>
<arg>--add-modules=[required modules]</arg>
</compilerArgs>
</configuration>
</plugin>
Property for JDK 10 (OpenJDK is fine):
<properties>
<java.home.openjdk10>[pathtoJDK20]\jdk-10.0.2</java.home.openjdk10>
</properties>
proguard-maven-plugin:
<plugin>
<groupId>com.github.dingxin</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>1.0.3</version>
<executions>
<execution>
<id>process-classes-with-proguard</id>
<phase>test</phase>
<goals>
<goal>proguard</goal>
</goals>
<configuration>
<options>
<option>[proguarg options]</option>
</options>
<libs>
<lib>${java.home.openjdk10}/lib/jrt-fs.jar</lib>
<lib>${java.home.openjdk10}/jmods/java.base.jmod(!.jar;!module-info.class)</lib>
<lib>${java.home.openjdk10}/jmods/java.compiler.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.corba.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.datatransfer.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.desktop.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.instrument.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.logging.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.management.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.management.rmi.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.naming.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.prefs.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.rmi.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.scripting.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.se.ee.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.se.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.security.jgss.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.security.sasl.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.smartcardio.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.sql.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.sql.rowset.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.transaction.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.xml.bind.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.xml.crypto.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.xml.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.xml.ws.annotation.jmod</lib>
<lib>${java.home.openjdk10}/jmods/java.xml.ws.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.accessibility.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.aot.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.attach.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.charsets.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.compiler.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.crypto.cryptoki.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.crypto.ec.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.crypto.mscapi.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.dynalink.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.editpad.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.hotspot.agent.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.httpserver.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.incubator.httpclient.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.internal.ed.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.internal.jvmstat.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.internal.le.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.internal.opt.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.internal.vm.ci.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.internal.vm.compiler.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.internal.vm.compiler.management.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jartool.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.javadoc.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jcmd.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jconsole.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jdeps.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jdi.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jdwp.agent.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jlink.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jshell.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jsobject.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.jstatd.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.localedata.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.management.agent.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.management.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.naming.dns.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.naming.rmi.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.net.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.pack.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.rmic.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.scripting.nashorn.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.scripting.nashorn.shell.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.sctp.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.security.auth.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.security.jgss.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.unsupported.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.xml.bind.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.xml.dom.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.xml.ws.jmod</lib>
<lib>${java.home.openjdk10}/jmods/jdk.zipfs.jmod</lib>
</libs>
</configuration>
</execution>
</executions>
</plugin>
Related
I am trying to add import-control to our checkstyle in such a way that the import-control file exists in the project making the checstyle.xml file and not in the projects we build later on.
We have a specific gradle project where we define all our rules and it is in this project our import-control.xml. My issue is that when I try to run mvn clean install on another project that uses this checkstyle it tries to locate import-control.xml in that project.
I did the following configuration in the checkstyle.xml:
<module name="ImportControl">
<property name="file" value="import-control.xml"/>
</module>
and the import-control.xml is placed next to checkstyle.xml.
Can anyone tell me what I need to do so that I can tell maven that this file exists in our checkstyle project and not in the root project that is being built?
Errors I have gotten are:
Cannot initialize module TreeWalker - cannot initialize module ImportControl - illegal value 'import-control.xml' for property 'file' Unable to find: import-control.xml
In v 2.17
Unable to load import-control.xml: unable to find file:/C://import-control.xml: \import-control.xml
What I have tried:
Upgrade checkstyle version to 3.1.0 (we used to have 2.17)
Use import-control.xml but didn't work.
Tried to read documentation and code but to no help.
Thanks for any help
Write you later / Mårten
mvn configuration:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>do checkstyle</id>
<phase>process-sources</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<includes>projectA/**/*</includes>
<configLocation>checkstyle.xml</configLocation>
<consoleOutput>true</consoleOutput>
<failOnViolation>false</failOnViolation>
<failsOnError>true</failsOnError>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
</configuration>
<dependencies>
<dependency>
<groupId>company.checkstyle</groupId>
<artifactId>company-checkstyle</artifactId>
<version>0.2-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>```
Thanks again barfuin, it seemed like ${config_loc} was the answer but we needed one more thing for it to fully work.
So, for adding resources from the checkstyle project, as in this file an import_control.xml I did as follow in my checkstyle.xml:
<module name="ImportControl">
<property name="file" value="${config_loc}/config/import_control.xml"/>
</module>
What I also needed to do was to add:
<propertyExpansion>config_loc=</propertyExpansion>
in my pom.xml configuration, this solved the issue with config_loc not being defined and for checkstyle to find the file as a resource and gave me the following pom.xml configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<executions>
<execution>
<id>do checkstyle</id>
<phase>process-sources</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<includes>projectA/**/*</includes>
<configLocation>checkstyle.xml</configLocation>
<consoleOutput>true</consoleOutput>
<failOnViolation>false</failOnViolation>
<failsOnError>true</failsOnError>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
<propertyExpansion>config_loc=</propertyExpansion>
</configuration>
<dependencies>
<dependency>
<groupId>company.checkstyle</groupId>
<artifactId>company-checkstyle</artifactId>
<version>0.2-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
</plugins>
We are using maven-jspc-plugin with java 8 and it’s giving class compilation errors though we are giving source and target as 1.6 java version.
So it’s not working with 1.8 or 1.6 java versions.
Unknown target VM 1.6 ignored.
Compilation error
org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
Arrays cannot be resolved
The type java.util.Comparator cannot be resolved. It is indirectly referenced from required .class files
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>maven-jspc-plugin</artifactId>
<executions>
<execution>
<id>compile-jsp</id>
<goals>
<goal>jspc</goal>
</goals>
<configuration>
<jasperClassDebugInfo>false</jasperClassDebugInfo>
<compilerSourceVM>1.6</compilerSourceVM>
<compilerTargetVM>1.6</compilerTargetVM>
</configuration>
</execution>
</executions>
</plugin>
I have an Ant project that builds just fine on its own. I'm now trying to wrap it in a Maven build that will kick off the Ant build using maven-antrun-plugin. When I do this the build fails and I get this error,
[ERROR] C:\Users\bobby\workspace\libraries\build-targets\common-targets.xml:170: Unable to find a javac compiler;
[ERROR] com.sun.tools.javac.Main is not on the classpath.
[ERROR] Perhaps JAVA_HOME does not point to the JDK.
[ERROR] It is currently set to "C:\Java\jdk1.8.0_65\jre"
There are a lot of SOF posts on this error but I feel like mine is unique since it only happens when I'm wrapping the Ant build in Maven i.e., I do not get this error on the same project when I just say $ ant build.
This is part of my pom.xml file
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>process-resources</phase>
<configuration>
<tasks>
<ant antfile="build.xml" target="build" />
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>add-jar</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>build/bin/myWarFile.war</file>
<type>war</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
My JAVA_HOME Environment Variable is set to C:\Java\jdk1.8.0_65.
The file that is mentioned in the error is from a library my work maintains where we keep all of our Jars. In that file here is what's on line 170
<target name="compile-src">
<!-- Compile source -->
<javac srcdir="${java.src.dir}"
destdir="${class.dir}"
debug="${debug.flag}"
deprecation="${deprecation.flag}"
nowarn="${warnings.flag}"
optimize="off"
source="${source.value}">
<classpath refid="compile.classpath"/>
</javac>
</target>
The line with source= is line 170.
It's a common issue. Try with this configuration:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
...
<!-- Add this dependency to your ant-run configuration -->
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
...
</plugin>
Maven uses Java's system property java.home, which is not the same as the environment variable JAVA_HOME, but it is using it to compute its java.home by tacking on the jre sub-directory, as witnessed. Consequently, stuff needed by Ant is simply not available in the jre directory.
However, this configuration ensures that Ant's plugin dependencies are correctly satisfied.
You need to point to JDK not JRE. Just remove ire and try.
It is currently set to "C:\Java\jdk1.8.0_65\jre"
And if your JDK is set - another workaround - Can you copy tools.jar from jdk lib to jre lib and see if it works.
I try to download Oracle (Sun) Java JDK via maven without success:
<dependency>
<groupId>com.sun</groupId>
<artifactId>jdk</artifactId>
<version>6u45</version>
<classifier>dlj-linux-i586</classifier>
<type>bin</type>
</dependency>
What maven repository should I use to download Oracle (Sun) Java JDK?
Added
I want to find a way to download DLJ version of jdk-6u45-linux-i586.bin JDK installer by maven, without manually download.
Now i have standard maven error when dependency is not configured well or a maven repository is missed:
Missing:
----------
com.sun:jdk:bin:dlj-linux-amd64:6u45
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.sun -DartifactId=jdk -Dversion=6u45 -Dclassifier=dlj-linux-amd64 -Dpackaging=bin -Dfile=/path/to/file
How to download JDK installer by maven?
You can't. The JDK installer is not in any public Maven repository. If it was, the Oracle lawyers would be sending "cease and desist" letters.
I am aware that you could use the Maven exec plugin (or similar) to "work around" Oracle's click through license agreement. However, this is arguably illegal under US law. Consider what happened to "weev" when prosecutors decided to make an example of him.
When you're running on a linux machine, you can download the jdk using maven-exec-plugin calling curl/wget :
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<!-- using curl -->
<execution>
<id>download oracle jdk (curl)</id>
<phase>process-resources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>curl</executable>
<arguments>
<argument>-L</argument>
<argument>--header</argument>
<argument>Cookie: s_nr=1359635827494; s_cc=true; gpw_e24=blub; s_sq=[[]]; gpv_p24=novalue</argument>
<argument>http://download.oracle.com/otn-pub/java/jdk/6u45-b06/jdk-6u45-linux-i586.bin</argument>
<argumen>-o</argumen>
<argument>${project.build.directory}/curl-jdk-6u45-linux-i586.bin</argument>
</arguments>
</configuration>
</execution>
<execution>
<!-- using wget -->
<id>download oracle jdk (wget)</id>
<phase>process-resources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>wget</executable>
<arguments>
<argument>--no-cookies</argument>
<argument>--header</argument>
<argument>Cookie: s_nr=1359635827494; s_cc=true; gpw_e24=blub; s_sq=[[]]; gpv_p24=no value</argument>
<argument>http://download.oracle.com/otn-pub/java/jdk/6u45-b06/jdk-6u45-linux-x64.bin</argument>
<argument>-O</argument>
<argument>${project.build.directory}/wget-jdk-6u45-linux-x64.bin</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
...
I have developed maven plugin which can download and unpack OpenJDK from different providers (Liberica, Adopt, SapMachine), it is useful for preparing cross-platform JDK images in distributives
<plugin>
<groupId>com.igormaznitsa</groupId>
<artifactId>mvn-jlink-wrapper</artifactId>
<version>1.0.2</version>
<executions>
<execution>
<id>cache-jdk-8</id>
<goals>
<goal>cache-jdk</goal>
</goals>
<configuration>
<jdkPathProperty>jlink.jdk.path</jdkPathProperty>
<jdkCachePath>${project.build.directory}${file.separator}jdkCache</jdkCachePath>
<provider>ADOPT</provider>
<providerConfig>
<release>jdk8u192-b12</release>
<arch>x64</arch>
<type>jdk</type>
<impl>hotspot</impl>
</providerConfig>
</configuration>
</execution>
</executions>
My maven project has a few modules: server, web, etc.
I would like to build all but my server module on Java 6. For the server module, I'd like to compile it with Java 7.
Here's my pom.xml below, but I think that if I modify it to 1.7, then all of my modules will be compiled with Java 7. Also, does maven use the JAVA_HOME environment variable to determine which Java version to use?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<memmax>2048m</memmax>
</configuration>
</plugin>
EDIT Also, does the below output of
maven --version
indicate that maven is compiling my java code with 1.7?
vagrant#dev:~/bin/apache-tomcat-7.0.29/bin$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+0000)
Maven home: /home/vagrant/bin/apache-maven-3.0.4
Java version: 1.7.0_07, vendor: Oracle Corporation
Java home: /home/vagrant/bin/jdk1.7.0_07/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.2.0-23-generic", arch: "amd64", family: "unix"
Thanks,
Kevin
There are a number of hacks out there for compiling source code with a different version of the JDK than you are using to run Maven, for example you can use something like
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<executable><!-- path-to-javac --></executable>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
The issue with this approach is that you now have hard-coded the path to the JDK into your POM. Everything will work just fine on your machine but when you have to rebuild your machine because the HDD failed, or when you want to build on a different machine, you will be stuck as the path will most likely not match up.
The correct best practice way to handle this is via Toolchains. This will see you creating a ~/.m2/toolchains.xml file that describes where each of the different toolchains in your system are. Then the version of the JDK can be applied by the Maven Toolchains Plugin, e.g.
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-toolchains-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>toolchain</goal>
</goals>
</execution>
</executions>
<configuration>
<toolchains>
<jdk>
<version>1.6</version>
</jdk>
</toolchains>
</configuration>
</plugin>
...
</plugins>
The next thing is that you don't need this as often as you would think. For example by using the source and target values you can generate the correct bytecode for the JRE that you are targeting... the only issue that you will then hit is the use of methods that are new in JRE 1.7... which is where Mojo's Animal Sniffer Plugin comes in. Animal Sniffer can be used to ensure that you only use the methods of the JRE that you are targeting. The general community consensus is that the use of source and target configuration options in the Maven Compiler Plugin configuration coupled with the use of Mojo's Animal Sniffer virtually eliminates the need for toolchains on the Compiler end of things.... on the Surefire end of things there is still need for toolchains... and I have a few edge cases that I need to update the compiler plugin and the toolchains plugins for to handle but, realistically you will not hit those edge cases ;-)
Just to be sure that your original question is completely answered (since the above answers the question you wanted to ask - as opposed to the one you asked)
At present you are compiling with JDK 1.7 however depending on the version of the Maven Compiler Plugin you are using, you may be compiling with either <source>1.4</source><target>1.4</target> or <source>1.5</source><target>1.5</target> unless you have changed the configuration of the Maven Compiler Plugin in your pom.xml. That will dictate which language features are available to you, but not which classes... so you would be generating code that will work on JRE 1.7 and provided you have not used any new classes/methods introduced since 1.4/1.5 (Such as String.isEmpty()) should also work on JRE 1.4/1.5... the only way to be sure if it works on such an old JVM is to either: run it on the old JVM OR use Animal Sniffer.
Maven Toolchains
To use multiple Java versions, you need to use Maven Toolchains, which require you to create a toolchains.xml file in your ~/.m2 Maven folder, containing all Java versions installed on your machine:
<toolchains>
<toolchain>
<type>jdk</type>
<provides>
<id>Java13</id>
<version>13</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_13}</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>Java9</id>
<version>9</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_9}</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>Java8</id>
<version>8</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_8}</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>Java7</id>
<version>7</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_7}</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>Java6</id>
<version>6</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_6}</jdkHome>
</configuration>
</toolchain>
</toolchains>
The JAVA_HOME_13, JAVA_HOME_9, JAVA_HOME_8, JAVA_HOME_7, JAVA_HOME_6 environment variables are configured so that they reference the path where the associated Java version is installed.
The FlexyPool parent pom.xml configuration file
The parent pom.xml Maven configuration file of the FlexyPool project defines the global Java version settings
<properties>
<jdk.version>8</jdk.version>
...
</properties>
Now, we need to instruct both the compiler and the test plugins to use the configured java version.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-toolchains-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<goals>
<goal>toolchain</goal>
</goals>
</execution>
</executions>
<configuration>
<toolchains>
<jdk>
<version>${jdk.version}</version>
</jdk>
</toolchains>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler-plugin.version}</version>
<configuration>
<source>${jdk.version}</source>
<target>${jdk.version}</target>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
</plugin>
</plugins>
</build>
The FlexyPool child Maven module pom.xml using a different Java version
The flexy-pool-core-java9 child Maven module that requires a different Java version only needs to override the default jdk.version Maven property:
<properties>
<jdk.version>9</jdk.version>
</properties>
And that's it, we can now build each module using its own minimum viable Java version.
use the setup for the JDK6 on your top pom, it will be inherited by all the module, and overwrite it for your server pom with the different configuration required.
As for the path of the JDK, you can specify it, see here: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html