Modular java module not found - gradle

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.

Related

Error running JavaFX Jar file built from NetBeans using Maven

I'm using the current NetBeans, and have just created a simple JavaFX project with the Maven compiler.
It runs, cleans, builds etc. perfectly fine, no errors, when in NetBeans.
However, when I navigate to the folder "...Documents\NetBeansProjects\Simple Banking Application\target" and run the executable Jar file, nothing happens. So I tried to run it manually via command line (Java -jar file.jar) it shows me the reason is because of an error:
No main manifest attribute
After searching, I found a supposed solution, involving adding these few lines to the POM.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.mycompany.mavenproject2.App</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
Unfortunately, that just causes a new error:
Error: Could not find or load main class com.mycompany.mavenproject2.App
Caused by: java.lang.NoClassDefFoundError: javafx/application/Application
I'm at a loss, and I'm wondering if I'm just missing something obvious. A couple of preliminary notes:
-I made sure to set this as my main project in NB
-I'm using default configuration
-I've tried cleaning and building, and just building as well, everything runs without any errors in NB
-I've not modified anything settings-wises
-I did refactor the project from mavenproject2 to Simple Banking Application, but I did so using NB's renaming options so that it does so 'safely'. (For the artifactID I had to remove the whitespaces)
-I've made sure all the .class files and .java files are in the project folder (.java are found in src, .class are found in target>classes)
Just in case, here is my entire POM.xml document:
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>SimpleBankingApplication</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>13</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.mycompany.mavenproject2.App</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.openjfx</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>0.0.4</version>
<configuration>
<mainClass>com.mycompany.mavenproject2.App</mainClass>
</configuration>
<executions>
<execution>
<!-- Default configuration for running -->
<!-- Usage: mvn clean javafx:run -->
<id>default-cli</id>
</execution>
<execution>
<!-- Configuration for manual attach debugging -->
<!-- Usage: mvn clean javafx:run#debug -->
<id>debug</id>
<configuration>
<options>
<option>-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:8000</option>
</options>
</configuration>
</execution>
<execution>
<!-- Configuration for automatic IDE debugging -->
<id>ide-debug</id>
<configuration>
<options>
<option>-agentlib:jdwp=transport=dt_socket,server=n,address=${jpda.address}</option>
</options>
</configuration>
</execution>
<execution>
<!-- Configuration for automatic IDE profiling -->
<id>ide-profile</id>
<configuration>
<options>
<option>${profiler.jvmargs.arg1}</option>
<option>${profiler.jvmargs.arg2}</option>
<option>${profiler.jvmargs.arg3}</option>
<option>${profiler.jvmargs.arg4}</option>
<option>${profiler.jvmargs.arg5}</option>
</options>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<name>Simple Banking Application</name>
</project>
You don't have the JavaFX components on your module path.
You can use a JDK which includes JavaFX (e.g. Azul JDK FX or Liberica Full JDK).
OR, you can follow the instructions below.
See the section on setting the VM arguments for running a JavaFX application as a jar file.
java --module-path /path/to/javafx-sdk-14/lib --add-modules javafx.controls,javafx.fxml -jar myJar.jar
You are using netbeans + maven, so refer to the official documentation openjfx.io JavaFX and NetBeans: modular with maven for more information. It discusses VM arguments for the Java module system to support JavaFX as well as creating runtime images using jlink.
If you don't know or understand the basics of the Java module system, then you should take some time to study and learn it from an appropriate tutorial. That will help you better understand the command line arguments required for the module system as well as the module-info.java alternative.
See the packaging instructions in the JavaFX tag which provide information on packaging alternatives (e.g. jlink and jpackage).
Use up-to-date software (e.g. JDK/JavaFX 18 and the maven-jar-plugin 0.0.8).
Don't use the maven-jar-plugin addClasspath option to build your jar when you have JavaFX component dependencies. The JavaFX components are not designed to be run from the classpath.

How to build an complete JavaFX JAR file? [duplicate]

I'm trying to create a JFX11 self-containing jar using maven dependencies. From the research I've done, it seems the best way to do this is through the maven shade plugin. However, When I run it, I get the this error:
Error: JavaFX runtime components are missing, and are required to run this application
I don't understand why this is happening. What am I messing up? Is there a better way to do this? I've also tried the maven assembly plugin with the same message.
pom file for reference
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>Application</groupId>
<artifactId>Main</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>SpaceRunner</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>11</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>10</release>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.6.0</version>
<executions>
<execution>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>Application.Main</mainClass>
</configuration>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>
Application.Main
</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>Application.Main</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
UPDATE 10/2021
Since JavaFX 16 a warning is displayed when JavaFX doesn't run on the module path, which is the case of an uber/fat jar:
$ java -jar myFatJar-1.0-SNAPSHOT.jar
Oct 02, 2021 1:45:21 PM com.sun.javafx.application.PlatformImpl startup
WARNING: Unsupported JavaFX configuration: classes were loaded from 'unnamed module #14c24f4c'
Also, you get a warning from the shade plugin itself:
[WARNING] Discovered module-info.class. Shading will break its strong encapsulation.
While these warnings can be initially ignored, there is a reason for them.
As explained in this CSR:
JavaFX is built and distributed as a set of named modules, each in its own modular jar file, and the JavaFX runtime expects its classes to be loaded from a set of named javafx.* modules, and does not support loading those modules from the classpath.
And:
when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we no longer get the benefit of the java module system.
Therefore, even this widely accepted answer explains how can an uber/fat jar can be created on Maven projects, its use is discouraged, and other modern alternatives to distribute your application, like jlink, jpackage or native-image, should be used.
ORIGINAL ANSWER
This answer explains why a fat/uber jar fails on JavaFX 11. In short:
This error comes from sun.launcher.LauncherHelper in the java.base module. The reason for this is that the Main app extends Application and has a main method. If that is the case, the LauncherHelper will check for the javafx.graphics module to be present as a named module. If that module is not present, the launch is aborted.
And already proposes a fix for Gradle.
For Maven the solution is exactly the same: provide a new main class that doesn't extend from Application.
You will have new class in your application package (bad name):
// NewMain.java
public class NewMain {
public static void main(String[] args) {
Main.main(args);
}
}
And your existing Main class, as is:
//Main.java
public class Main extends Application {
#Override
public void start(Stage stage) {
...
}
public static void main(String[] args) {
launch(args);
}
}
Now you need to modify your pom and set your main class for the different plugins:
<mainClass>application.NewMain</mainClass>
Platform-specific Fat jar
Finally, with the shade plugin you are going to produce a fat jar, on your machine.
This means that, so far, your JavaFX dependencies are using a unique classifier. If for instance you are on Windows, Maven will be using internally the win classifier. This has the effect of including only the native libraries for Windows.
So you are using:
org.openjfx:javafx-controls:11
org.openjfx:javafx-controls:11:win
org.openjfx:javafx-graphics:11
org.openjfx:javafx-graphics:11:win <-- this contains the native dlls for Windows
org.openjfx:javafx-base:11
org.openjfx:javafx-base:11:win
Now, if you produce the fat jar, you will bundle all those dependencies (and those other regular third party dependencies from your project), and you will be able to run your project as:
java -jar myFatJar-1.0-SNAPSHOT.jar
While this is very nice, if you want to distribute you jar, be aware that this jar is not cross-platform, and it will work only on your platform, in this case Windows.
Cross-Platform Fat Jar
There is a solution to generate a cross-platform jar that you can distribute: include the rest of the native libraries of the other platforms.
This can be easily done, as you just need to include the graphics module dependencies for the three platforms:
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>11</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-graphics </artifactId>
<version>11</version>
<classifier>win</classifier>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-graphics </artifactId>
<version>11</version>
<classifier>linux</classifier>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-graphics </artifactId>
<version>11</version>
<classifier>mac</classifier>
</dependency>
</dependencies>
Size
There is a main issue with this approach: the size. As you can see in this other answer, if you use the WebView control, you will be bundling around 220 MB due to the WebKit native libraries.

Groovy and Maven: Stuck in compiling and testing a very simple

I am stuck trying to compile and test a extremely simple project. It's a beginner project in order to understand how all of this works, and I am currently stucked.
My main objective is to understand how to handle resources files that are located outside of the standard folder structure.
I have a main class, with two methods. One load a resource file which is on the standard folder structure (src\main\resources). Another one load a resource which is in a custom folder, outside of the standard structure (resources).
There is one junit file that simply verify that the resource is correctly loaded.
It works fine with IntelliJ. I simply declared the resources folder as resources folders and that's it.
Now with maven ..... actually I can't even compile with gmaven-plus. Nor run the test. So I did not even bother to declare the custom folder as a resource in the pom.xml file.
I based my pom.xml file based on an existing pom we have at work and from stuff I read on the web. There's no way I can make it work.
Here is a link to a 7zip file with my project, if one could put me on the right track, I would be grateful.
https://www.dropbox.com/s/jvn32ll5xfvjfwd/GroovyExample.7z?dl=0
Here is the pom:
<?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>groupId</groupId>
<artifactId>Example</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.4.13</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.4.0</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.8.1</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compileTests</goal>
</goals>
<configuration>
<sources>
<source>
<directory>src/main/groovy</directory>
<includes>
<include>**/*.groovy</include>
</includes>
</source>
</sources>
<testSources>
<testSource>
<directory>src/test/groovy</directory>
<includes>
<include>**/*.groovy</include>
</includes>
</testSource>
</testSources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M1</version>
<configuration>
<failIfNoTests>true</failIfNoTests>
<testSourceDirectory>str/test/</testSourceDirectory>
<includes>
<include>**/*Test*.*</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
</project>
Here is the output:
Unable to get Groovy version from InvokerHelper or GroovySystem,
trying jar name.
Failed to execute goal
org.codehaus.gmavenplus:gmavenplus-plugin:1.8.1:compile (default) on
project Example: Execution default of goal
org.codehaus.gmavenplus:gmavenplus-plugin:1.8.1:compile failed.
The 2.4 groovy-all POMs do not include Groovy as a dependency, because they are a POM for an uber-jar, rather than a POM that describes all the Groovy module jars. Because of this, GMavenPlus is unable to find the Groovy jar to use for compilation. The <type>pom</type> works for Groovy 2.5, and 3.0, but not 2.4. So for your use case, simply delete the <type>pom</type> (or replace it with the default of <type>jar</type>). This was the way Groovy was often included back before 2.5, so the groovy-all POMs of 2.5 and 3.0 were added to ease the transition. See https://groovy-lang.org/releasenotes/groovy-2.5.html#Groovy2.5releasenotes-Packaging.

Maven can't compile java 1.8

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.

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