Maven can't compile java 1.8 - maven

I'm trying to use maven to build a jar but I keep getting the error
ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project Application: Fatal error compiling: invalid target release: 1.8 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
mvn -v outputs
mvn -version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T09:29:23-08:00)
Maven home: /usr/local/Cellar/maven/3.2.5/libexec
Java version: 1.6.0_65, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.10.1", arch: "x86_64", family: "mac"
So it looks like its pointing to the 1.6jdk
but I have the 1.8 jdk
java -version
java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
POM.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.brian.ridecellchallenge</groupId>
<artifactId>Application</artifactId>
<version>0.0.1-SNAPSHOT</version>
<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.group.id.Launcher1</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.4</version>
</dependency>
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>2.6</version>
</dependency>
</dependencies>
</project>

Maven relies on the JAVA_HOME environment variable being set. Set it according to your OS and re-run your build.
Edit:
Use export to set the variable.
export JAVA_HOME=/path/to/java

As a MacOS user, open a Terminal and create or edit a file .bash_profile (in the directory of your user home) and put the following snippet there:
export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
Save that file and reopen a Terminal instance. If you execute export as a command there, you should see a valid JAVA_HOME with the location of your JDK 8 installation. Restart your IDE afterwards and maven should be able to build you nice java target 1.8 code.

Because Maven does not know version of jdk you want to build.
You can try with
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>

you can try configuration in compiler plugin. Its working on my local
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<executable><!--path-to-your-java8-home-directoru--></executable>
<compilerVersion>1.8</compilerVersion>
</configuration>
</plugin>

I noticed that it seems that maven-compiler-plugin ignores the configurations
<source>1.8</source>
<target>1.8</target>
In fact, building my project with -X maven's option, I see that in the configuration of the maven-compiler-plugin the source and target were forced to be 1.6:
[DEBUG] --------------------------------------------------------------
[DEBUG] Goal: org.apache.maven.plugins:maven-compiler-plugin:3.3:testCompile (default-testCompile)
[DEBUG] Style: Regular
[DEBUG] Configuration: <?xml version="1.0" encoding="UTF-8"?>
<configuration>
<basedir default-value="${basedir}"/>
<buildDirectory default-value="${project.build.directory}"/>
<classpathElements default-value="${project.testClasspathElements}"/>
<compileSourceRoots default-value="${project.testCompileSourceRoots}"/>
<compilerId default-value="javac">${maven.compiler.compilerId}</compilerId>
<compilerReuseStrategy default-value="${reuseCreated}">${maven.compiler.compilerReuseStrategy} </compilerReuseStrategy>
<compilerVersion>${maven.compiler.compilerVersion}</compilerVersion>
<debug default-value="true">${maven.compiler.debug}</debug>
<debuglevel>${maven.compiler.debuglevel}</debuglevel>
<encoding default-value="${project.build.sourceEncoding}">UTF-8</encoding>
<executable>${maven.compiler.executable}</executable>
<failOnError default-value="true">${maven.compiler.failOnError}</failOnError>
<forceJavacCompilerUse default-value="false">${maven.compiler.forceJavacCompilerUse}</forceJavacCompilerUse>
<fork default-value="false">${maven.compiler.fork}</fork>
<generatedTestSourcesDirectory default-value="${project.build.directory}/generated-test-sources/test-annotations"/>
<maxmem>${maven.compiler.maxmem}</maxmem>
<meminitial>${maven.compiler.meminitial}</meminitial>
<mojoExecution default-value="${mojoExecution}"/>
<optimize default-value="false">${maven.compiler.optimize}</optimize>
<outputDirectory default-value="${project.build.testOutputDirectory}"/>
<project default-value="${project}"/>
<session default-value="${session}"/>
<showDeprecation default-value="false">${maven.compiler.showDeprecation}</showDeprecation>
<showWarnings default-value="false">${maven.compiler.showWarnings}</showWarnings>
<skip>${maven.test.skip}</skip>
<skipMultiThreadWarning default-value="false">${maven.compiler.skipMultiThreadWarning}</skipMultiThreadWarning>
<source default-value="1.5">1.6</source>
<staleMillis default-value="0">${lastModGranularityMs}</staleMillis>
<target default-value="1.5">1.6</target>
<testSource>${maven.compiler.testSource}</testSource>
<testTarget>${maven.compiler.testTarget}</testTarget>
<useIncrementalCompilation default-value="true">${maven.compiler.useIncrementalCompilation}</useIncrementalCompilation>
<verbose default-value="false">${maven.compiler.verbose}</verbose>
I solved the problem after much much searches and tries, by forcing the java compiler to use the desired source and target:
<compilerArguments>
<source>1.8</source>
<target>1.8</target>
</compilerArguments>
This adds to the parameters of javac the two parameters above, overwriting the default.
In my case, all works well.
Just a note: I see that with the above configuration, maven calls the javac in this way:
-d [...] -g -nowarn -target 1.6 -source 1.6 -encoding UTF-8 -source 1.8 -target 1.8
The first two "-source" and "-target" parameters are the default parameters that the maven-compiler-plugin uses; the second couple of parameters are the parameters added by the plugin because of the configuration "compilerArguments" described above. It seems that javac just uses the last couple of parameters (if a parameter is repeated more times, the last one overwrites all the previouses), but I'm not sure that this can be considered a standard and "sure" behavior.
I used different versions of maven-compiler-plugin, different version of maven. I checked in deep all my configurations (e.g. system variables, every single script used in execution of java or maven and so on) and I'm sure that all is ok.
It's strange, but my conclusion is that there is a bug in the maven-compiler-plugin with java 8.

I'm not sure but can you try to update your maven.plugin version
try
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
<version>3.6.1</version>
</plugin>

If anybody has Eclipse Kepler SR2 and has an issue with Java 1.8 while building project with Maven, try to go to Eclipse Marketplace and search for plugin called Java 8 support for m2e for Eclipse Kepler SR2 this helped me, and now Maven compiles Java 1.8 source without problem.

Yes it seems a bug in the maven-compiler-plugin.When I upgraded from 3.1 to 3.5.1, it works.

Related

Modular java module not found

I read all of the modular documentation but still cannot figure out what the problem is here: I added a dependency via Maven (I also tried adding the jar into project library manually but still caused the same problem), but when I import the class from that particular into my class, IntelliJ says "package com.fazecast.jSerialComm is declared in module 'com.fazecast.jSerialComm' but module com.greeting does not read it".
It gives me two options: Either add it as Maven dependency which I already did (it is in my pom.xml and can see it under dependencies) or "add requires com.fazecast.jSerialComm directive to module-info.java". If I add requires com.fazecast.jSerialComm, it compiles fine, but when I create my modular jar and try to run the jar with java -p mods/ -m com.greeting/com.mayapp.Runner, it tells me "java.lang.module.FindException: Module com.fazecast.jSerialComm not found, required by com.greeting".
I also tried more jars/dependencies which I have and it gave me the same problem. I tried Java 9 and 10, also with Gradle, and created artifact via IntelliJ. Got the same exception. My module-info.java is in src/main/java as where my app starts. Any help will be highly appreciated.
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00)
Maven home: C:\Apache\apache-maven-3.5.4-bin\apache-maven-3.5.4\bin\..
Java version: 9.0.4, vendor: Oracle Corporation, runtime: C:\Program iles\Java\jdk-9.0.4 Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Intelli J 2018.1.6
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.myapp</groupId>
<artifactId>greet</artifactId>
<version>1.0-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>10</source>
<target>10</target>
<release>9</release>
<executable>javac10</executable>
<compilerArgs>
<arg>-Xlint:all,-processing</arg>
</compilerArgs>
<showWarnings>true</showWarnings>
<showDeprecation>true</showDeprecation>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.fazecast</groupId>
<artifactId>jSerialComm</artifactId>
<version>2.0.2</version>
<scope>compile</scope>
</dependency>
</dependencies>
</project>
package com.myapp;
import com.fazecast.jSerialComm.SerialPort;
public class Runner {
public static void main(String[] args) {
System.out.println("Runner");
}
}
module com.greeting {
requires com.fazecast.jSerialComm;
}
If you develop a module (as indicated by your module-info.java), all dependencies need to be required (that's the quick fix IntelliJ recommended) and need to be on the module path (instead of the class path) for compilation and launch. For compilation, Maven, Gradle, and IntelliJ do the right thing and when launching your app from IntelliJ, it will do that as well.
The problem most likely lies with your java command:
java -p mods/ -m com.greeting/com.mayapp.Runner
It points to mods as the module path, but unless you forgot to mention some steps you undertook, that folder does not contain your app's dependencies, so when Java goes looking for them, it will not find them - thus the error message.
To get your dependencies into that folder you can either copy them manually (don't forget transitive dependencies) or use Maven's copy-dependencies mojo for that:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/../mods</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
When you run mvn package or mvn install, you will find all dependencies, including transitive ones, in mods and then your command should work.

Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin: 3.2:sonar

Can anyone help me in getting solution for the below error.
Below are the version of the components to configure
SonarQube 5.1.2
Soanr-Runner 2.4
Java 1.7 [ I have to use 1.7 only since my code supports only 1.7]
mavn 3.3.9
sonar-cobertura-plugin-1.6.3
sonar-findbugs-plugin-3.3
cobertura 2.6
Execution command
mvn -fn -e org.sonarsource.scanner.maven:sonar-maven-plugin:RELEASE:sonar -Dsonar.jdbc.url="jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true&useConfigs=maxPerformance" -Dsonar.host.url=http://localhost:9000 -DskipTests
In Console Window I am getting error
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:
3.2:sonar (default-cli) on project NWT_Core: Execution default-cli of goal org.s
onarsource.scanner.maven:sonar-maven-plugin:3.2:sonar failed: Unable to load the
mojo 'sonar' in the plugin 'org.sonarsource.scanner.maven:sonar-maven-plugin:3.
2' due to an API incompatibility: org.codehaus.plexus.component.repository.excep
tion.ComponentLookupException: org/sonarsource/scanner/maven/SonarQubeMojo : Unsupported major.minor version 52.0
Since the 3.2, the SonarQube maven plugin requires Java 8.
You have to use the 3.0.2 version for Java 7.
You have to explicitely add this statement to your pom :
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.0.2</version>
</plugin>
Because if you do not do so, by default this plugin uses the LATEST version of the plugin (3.2), hence your error.
See http://docs.sonarqube.org/display/HOME/Frequently+Asked+Questions#FrequentlyAskedQuestions-ShouldIlockversionofSonarQubeMavenplugininmypom.xml?
Regardless of what you compile your code with, the SonarQube analysis should be run with a specific Java version.
You simply need to use different JDK versions for the compilation and analysis.
For SonarQube 6.* compatibility], make sure the JAVA_HOME=/path/to/java8
For SonarQube 9.* compatibility], make sure the JAVA_HOME=/path/to/java11
In my case I had a parent pom with
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.sonar</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>2.5</version>
</plugin>
</plugins>
</pluginManagement>
</build>
I've added my own version also within pluginManagement in my child pom but this didn't work I had to add the plugin to the <build><plugins> nodes instead of <build><pluginManagement><plugins>. Only then new newer version had been used.
Maybe this helps someone.
Recently, install Sonorqube.5.12 image in docker and push the project into Sonorqube. Initially we were facing some maven console errors like major.minor version 52.0.
Later, has been fixed by below step's for me.
Add this plugs in maven.
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>2.6</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
</plugin>
</plugins>
Next, Add default DB setup in ~/.m2/settings.xml file
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<sonar.jdbc.url>jdbc:h2:tcp://localhost:9092/sonar</sonar.jdbc.url>
<sonar.host.url>http://localhost:9000</sonar.host.url>
<sonar.jdbc.username>sonar</sonar.jdbc.username>
<sonar.jdbc.password>sonar</sonar.jdbc.password>
<sonar.pdf.username>admin</sonar.pdf.username>
<sonar.pdf.password>admin</sonar.pdf.password>
</properties>
</profile>
It worked for me after using Maven->update project , mvn clean install, mvn clean compile

Error when using groovy-eclipse-plugin and #Grab

Getting the following error when running mvn clean compile on a new system. It works fine on my local (windows) environment.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project visa-threatintel: Compilation failure: Compilation failure:
[ERROR] /path/to/Class.groovy:[2,2] 1. ERROR in /path/to/Class.groovy (at line 2)
[ERROR] #Grab(group="javax.mail", module="mail", version="1.5.0-b01", type="jar"),
[ERROR] ^^^
[ERROR] Groovy:Ambiguous method overloading for method org.apache.ivy.core.settings.IvySettings#load.
Both local and new system use Maven 3.2.5 and the POM is identical. Relevant excerpts below:
<groovy.version>2.2.1</groovy.version>
<ivy.version>2.4.0</ivy.version>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<extensions>true</extensions>
<configuration>
<!-- http://maven.apache.org/plugins/maven-compiler-plugin/ -->
<source>1.6</source>
<target>1.6</target>
<compilerId>groovy-eclipse-compiler</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.9.0-01</version>
</dependency>
<!-- 2.2.1 version isn't available as a release, so it needs to be acquired
from the codehaus nexus repository -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>${groovy.version}-01-SNAPSHOT</version>
</dependency>
<!-- to allow #Grab annotations -->
<dependency>
<groupId>org.apache.ivy</groupId>
<artifactId>ivy</artifactId>
<version>${ivy.version}</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.9.1</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/main/groovy</source>
</sources>
</configuration>
</execution>
I tried changing groovy version to 2.4.3 but got the same error. Anyone seen anything like this before?
Having just encountered a similar issue, I found that I had two issues:
Maven deps that failed a download
A maven dependency (maven-assembly-plugin) had failed a download.
Deleting the .lastUpdated files in your local m2 repository:
#> find ~/.m2/repository -name *.lastUpdated
~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-5/maven-assembly-plugin-2.2-beta-5.pom.lastUpdated
#> find ~/.m2/repository -name *.lastUpdated -delete
grapeConfig.xml & repository ssl certificate
Also your ~/.groovy/grapeConfig.xml file needs to be configured to tell groovy where to pull the dependencies from - in my case it was from a corporate nexus repository, which also meant i had to install the https certificate in the JRE cacerts file.
How to test
One suggestion to test you have everything set up correctly would be to call grape install on a test dependency and that will give you a clearer sense of what is wrong (grape is distributed as part of the groovy binaries, so include it on your path, or fully qualify its path):
grape install javax.mail mail 1.5.0-b01

How can I configure Maven to use JDK6 by default, but JDK7 as needed

I have both JDK 1.6 and 1.7 installed on my system (Linux, under the /opt directory).
I've added the bin directory for JDK 1.6 in my path, so that's the version of Java used by default.
I'm working on a project that requires JDK 1.7 and some that require 1.6. Previously I had set JDK 1.7 settings within Eclipse, but I wanted to convert this project to Maven so that everyone could use their preferred editor.
Is it possible to specify the 1.7 location on a Maven installation/configuration (and not in the POM file) such that it uses 1.6 by default and 1.7 when specifying the project requires it in the POM? As far as I am aware, everyone working on a project should have the same contents in their POM files, so I am reluctant to set the location of the Java 7 directory here (as it'll be different on everyone's machines).
$ mvn --version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+0000)
Maven home: /opt/apache-maven-3.0.5
Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
Java home: /opt/jdk1.6.0_45/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.8.0-27-generic", arch: "amd64", family: "unix"
Adding the following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<configuration>
<outputDirectory>${project.build.outputDirectory}/resources</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
results in:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project golemlite: Fatal error compiling: invalid target release: 1.7 -> [Help 1]
Take a look here. You can set a property in your settings.xml and use it in the pom. Be aware that everybody would have to define that property.
As for your example:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<fork>true</fork>
<executable>${JAVA_1_7_HOME}/bin/javac</executable>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<configuration>
<outputDirectory>${project.build.outputDirectory}/resources</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
and in the settings:
<settings>
[...]
<profiles>
[...]
<profile>
<id>compiler</id>
<properties>
<JAVA_1_7_HOME>/path/to/jdk7</JAVA_1_7_HOME>
</properties>
</profile>
</profiles>
[...]
<activeProfiles>
<activeProfile>compiler</activeProfile>
</activeProfiles>
</settings>
You can place a file named mvn.sh near your pom.xml in which you set JAVA_HOME to anything you want. Then, build project like ./mvn clean install. And be sure not to check it to VCS.
Maven uses whatever version is in your JAVA_HOME system variable. So I like to add to my .bash_profile functions to swap between them just in my current shell, so you could leave Java 6 by default but allow yourself to trivially switch to Java 7 or even 8 when you need to build a newer project.
Gist to Change Java Versions on Demand
If your terminal is not bash then you may need to tweak this solution.
Personally I prefer this to setting it in your settings.xml even though it is slightly more work as it allows you to use the same solution across all build tools and even just for running jars built targeting other versions of Java.
So a solution for you might be adding something like this to your .bash_profile (clearly tweaking the paths appropriately to where ever the Java versions are installed on your machine):
function java6
{
JAVA_HOME=/Library/Java/JavaVirtualMachines/1.6.0_65-b14-462.jdk/Contents/Home
export JAVA_HOME
}
function java7
{
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home
export JAVA_HOME
}

Compile Maven Module with Different Java Version

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

Resources