Develop Reference

How to exclude a Maven dependency from the environment of an annotation processor?

Context
I have code that uses maven-processor-plugin to have Hibernate generate some classes in folder src/main/generated of a Java project. I am preparing the migration of the project to Java 11, in the development environment as well as in the runtime environment.
Until now, everything worked fine with Hibernate 4.3.10.Final and Java 8. After installing JDK 11 and using Hibernate 5.4.4.Final, I've come across the infamous javax.annotation.Generated problem.
Since Hibernate 5.4.4.Final is supposed to be compatible with Java 9+, I was expecting the generated files to switch to javax.annotation.processing.Generated. Unfortunately, the old qualified name is the one that I can still see in those files, in the imports section. As a consequence, the compilation of generated files will fail.
Here is what I configured:
maven-processor-plugin, with <releaseVersion>11</releaseVersion>
The target level in pom.xml, with <maven.compiler.target>1.11</maven.compiler.target>
The release in pom.xml, with <maven.compiler.release>11</maven.compiler.release>
In Eclipse, the Java compiler is using the '--release' option and set to compliance level "11".
On the system, there's only one JDK installed: 11.0.4.
On further investigation, I have realized that the Context class in org.hibernate:hibernate-jpamodelgen:5.4.4.Final has this code:
TypeElement java8AndBelowGeneratedAnnotation =
pe.getElementUtils().getTypeElement( "javax.annotation.Generated" );
if ( java8AndBelowGeneratedAnnotation != null ) {
generatedAnnotation = java8AndBelowGeneratedAnnotation;
}
else {
// Using the new name for this annotation in Java 9 and above
generatedAnnotation = pe.getElementUtils().getTypeElement( "javax.annotation.processing.Generated" );
}
Question
Essentially, the Hibernate annotation processor tries to determine which correct annotation (of javax.annotation.Generated and javax.annotation.processing.Generated) to output in the generated files by trying to get a reference to the Java 8 javax.annotation.Generated type. I guess the premise is that that type would not exist in a Java 9+ environment.
But unfortunately for me, javax.annotation:jsr250-api is indirectly pulled by org.bsc.maven:maven-processor-plugin as a transitive dependency into the build environment of my project.
My question is therefore: how can I exclude that transitive dependency from the environment that is passed to the Hibernate annotation processor?
I'm also wondering whether it's an issue that I should report to Hibernate or the maven-processor-plugin projects.

What I did that works is shown below.
A thing to note is that there needs to be an intermediate artifact between the root plugin (maven-processor-plugin in this case) and the dependency to exclude (jsr250-api in this case).
My earlier mistake was that I was listing maven-processor-plugin again in lieu of maven-plugin-api, which of course did not make sense.
<pluginManagement>
...
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>${maven-processor-plugin-version}</version>
<configuration>
<releaseVersion>${maven.compiler.release}</releaseVersion>
</configuration>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<outputDirectory>src/main/generated</outputDirectory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>${maven-plugin-api-version}</version>
<exclusions>
<!--
Exclude this artifact because it defines 'javax.annotation.Generated', which makes the
generated source code incompatible with Java 11.
-->
<exclusion>
<groupId>javax.annotation</groupId>
<artifactId>jsr250-api</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</plugin>
...
</pluginManagement>

Is there a maven jigsaw jlink plugin?

Does maven have a plugin for the new Java 9 jlink I have searched online but have not been able to find anything official from the maven team.

Yes. There has been some progress made to create one on Github/maven-plugins for the same.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jlink-plugin</artifactId>
<version>3.0.0-SNAPSHOT</version>
</plugin>
The plugin in its code reads to be adaptive to JEP-282 and JEP-220 from the proposals.
And though this might look like a link too many answer. There is a working example from #khmarbaise on Github as well for this, which requires a toolchain with -
<configuration>
<jdkHome>/Library/Java/JavaVirtualMachines/jdk1.9.0_ea+170.jdk/Contents/Home</jdkHome>
</configuration>
Plus a side note from the author quoting -
Currently not more than a Proof of Concept. Everything here is speculative!
Edit1:- As shared in the comments, additional details could be found # How to create a Java runtime with Maven.
Edit2:- Dated 10 November, 2018 one can upgrade to using maven-jlink-plugin:3.0.0-alpha-1 and still provide some valuable feedback.

I'm working on ModiTect, general tooling around Java 9 modules. One of the goals of the ModiTect Maven plug-in lets you create module runtime images via jlink:
<plugin>
<groupId>org.moditect</groupId>
<artifactId>moditect-maven-plugin</artifactId>
<version>1.0.0-SNAPSHOT</version>
<executions>
<execution>
<id>create-runtime-image</id>
<phase>package</phase>
<goals>
<goal>create-runtime-image</goal>
</goals>
<configuration>
<modulePath>
<path>${project.build.directory}/modules</path>
</modulePath>
<modules>
<module>com.example.module1</module>
<module>com.example.module2</module>
</modules>
<launcher>
<name>helloWorld</name>
<module>com.example.module1</module>
</launcher>
<outputDirectory>
${project.build.directory}/jlink-image
</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
The plug-in is under active development right now and must be built from source for the time being (will deploy a first version to Maven Central soon).

there is mvn-jlink plugin which allows to call jdeps and jlink (and any tool provided by jdk), also it can download and unpack needed openjdk version from ADOPT and LIBERICA, such way allows build cross-platform images
<plugin>
<groupId>com.igormaznitsa</groupId>
<artifactId>mvn-jlink-wrapper</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<id>call-jlink</id>
<goals>
<goal>jlink</goal>
</goals>
<configuration>
<jdepsReportPath>${project.build.directory}${file.separator}jdeps.out</jdepsReportPath>
<output>${project.build.directory}${file.separator}preparedJDK</output>
<addModules>
<module>java.compiler</module>
</addModules>
<options>
<option>--compress=2</option>
<option>--no-header-files</option>
<option>--no-man-pages</option>
</options>
</configuration>
</execution>
</executions>
</plugin>

Maybe check out https://github.com/ghackenberg/jigsaw-maven-plugin. The plugin also supports
jdeps --generate-module-info + javac + jar for patching unnamed modules,
jlink for creating runtime images, and
jpackage for creating application installers (only available since JDK 14 though).
You find the plugin documentation on the Github README page.
<plugin>
<groupId>io.github.ghackenberg</groupId>
<artifactId>jigsaw-maven-plugin</artifactId>
<version>1.1.3</version>
</plugin>

Specifying Java version in maven - differences between properties and compiler plugin

I'm not very experienced with Maven and while experimenting with multi-module project I started wondering how can I specify Java version for all my child modules in parent Maven pom. Until today I was using just:
<properties>
<java.version>1.8</java.version>
</properties>
...but when researching I found that you can also specify Java version in Maven compiler plugin, like that:
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
And then wrap this into plugin management tag to enable child poms usage of this. So the first question is this:
What are the differences beetwen setting Java version in properties and in Maven compiler plugin?
I couldn't find clear answer but in process of researching I found that you can also specify Java version in this way:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
...which suggest that compiler plugin is there even if I don't explicit declare it. Running mvn package outputs with
maven-compiler-plugin:3.1:compile (default-compile) # testproj ---
...and some other plugins that I didn't declare.
So are those plugins default, hidden part of Maven pom? Are there any differences between setting source/target in properties and in Maven plugin configuration element?
Some other questions are - which way should be used (and when if they are not equal)? Which one is best for multi-module project and what happens if Java version specified in pom is different than version pointed in JAVA_HOME?

How to specify the JDK version?
Use any of three ways: (1) Spring Boot feature, or use Maven compiler plugin with either (2) source & target or (3) with release.
Spring Boot
<java.version> is not referenced in the Maven documentation.
It is a Spring Boot specificity.
It allows to set the source and the target java version with the same version such as this one to specify java 1.8 for both :
1.8
Feel free to use it if you use Spring Boot.
maven-compiler-plugin with source & target
Using maven-compiler-plugin or maven.compiler.source/maven.compiler.target properties are equivalent.
That is indeed :
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
is equivalent to :
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
according to the Maven documentation of the compiler plugin
since the <source> and the <target> elements in the compiler configuration use the properties maven.compiler.source and maven.compiler.target if they are defined.
source
The -source argument for the Java compiler.
NOTE: Since 3.8.0 the default value has changed from 1.5 to 1.6. Since 3.9.0 the default value has changed from 1.6 to 1.7
Default value is: 1.7.
User property is: maven.compiler.source.
target
The -target argument for the Java compiler.
NOTE: Since 3.8.0 the default value has changed from 1.5 to 1.6. Since 3.9.0 the default value has changed from 1.6 to 1.7
Default value is: 1.6.
User property is: maven.compiler.target.
About the default values for source and target, note that
since the 3.8.0 of the maven compiler, the default values have changed from 1.5 to 1.6.
maven-compiler-plugin with release instead of source & target
The maven-compiler-plugin 3.6 and later versions provide a new way :
org.apache.maven.plugins
maven-compiler-plugin
3.8.0
9
You could also declare just :
<properties>
<maven.compiler.release>9</maven.compiler.release>
</properties>
But at this time it will not work as the maven-compiler-plugin default version you use doesn't rely on a recent enough version.
The Maven release argument conveys release : a new JVM standard option that we could pass from Java 9 :
Compiles against the public, supported and documented API for a
specific VM version.
This way provides a standard way to specify the same version for the source, the target and the bootstrap JVM options.
Note that specifying the bootstrap is a good practice for cross compilations and it will not hurt if you don't make cross compilations either.
Which is the best way to specify the JDK version?
The first way (<java.version>) is allowed only if you use Spring Boot.
For Java 8 and below :
About the two other ways : valuing the maven.compiler.source/maven.compiler.target properties or using the maven-compiler-plugin, you can use one or the other. It changes nothing in the facts since finally the two solutions rely on the same properties and the same mechanism : the maven core compiler plugin.
Well, if you don't need to specify other properties or behavior than Java versions in the compiler plugin, using this way makes more sense as this is more concise:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
From Java 9 :
The release argument (third point) is a way to strongly consider if you want to use the same version for the source and the target.
What happens if the version differs between the JDK in JAVA_HOME and which one specified in the pom.xml?
It is not a problem if the JDK referenced by the JAVA_HOME is compatible with the version specified in the pom but to ensure a better cross-compilation compatibility think about adding the bootstrap JVM option with as value the path of the rt.jar of the target version.
An important thing to consider is that the source and the target version in the Maven configuration should not be superior to the JDK version referenced by the JAVA_HOME.
A older version of the JDK cannot compile with a more recent version since it doesn't know its specification.
To get information about the source, target and release supported versions according to the used JDK, please refer to java compilation : source, target and release supported versions.
How handle the case of JDK referenced by the JAVA_HOME is not compatible with the java target and/or source versions specified in the pom?
For example, if your JAVA_HOME refers to a JDK 1.7 and you specify a JDK 1.8 as source and target in the compiler configuration of your pom.xml, it will be a problem because as explained, the JDK 1.7 doesn't know how to compile with.
From its point of view, it is an unknown JDK version since it was released after it.
In this case, you should configure the Maven compiler plugin to specify the JDK in this way :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
<compilerVersion>1.8</compilerVersion>
<fork>true</fork>
<executable>D:\jdk1.8\bin\javac</executable>
</configuration>
</plugin>
You could have more details in examples with maven compiler plugin.
It is not asked but cases where that may be more complicated is when you specify source but not target. It may use a different version in target according to the source version. Rules are particular : you can read about them in the Cross-Compilation Options part.
Why the compiler plugin is traced in the output at the execution of the Maven package goal even if you don't specify it in the pom.xml?
To compile your code and more generally to perform all tasks required for a maven goal, Maven needs tools. So, it uses core Maven plugins (you recognize a core Maven plugin by its groupId : org.apache.maven.plugins) to do the required tasks : compiler plugin for compiling classes, test plugin for executing tests, and so for... So, even if you don't declare these plugins, they are bound to the execution of the Maven lifecycle.
At the root dir of your Maven project, you can run the command : mvn help:effective-pom to get the final pom effectively used. You could see among other information, attached plugins by Maven (specified or not in your pom.xml), with the used version, their configuration and the executed goals for each phase of the lifecycle.
In the output of the mvn help:effective-pom command, you could see the declaration of these core plugins in the <build><plugins> element, for example :
...
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>default-clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>default-testResources</id>
<phase>process-test-resources</phase>
<goals>
<goal>testResources</goal>
</goals>
</execution>
<execution>
<id>default-resources</id>
<phase>process-resources</phase>
<goals>
<goal>resources</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<executions>
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
<execution>
<id>default-testCompile</id>
<phase>test-compile</phase>
<goals>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>
...
You can have more information about it in the introduction of the Maven lifeycle in the Maven documentation.
Nevertheless, you can declare these plugins when you want to configure them with other values as default values (for example, you did it when you declared the maven-compiler plugin in your pom.xml to adjust the JDK version to use) or when you want to add some plugin executions not used by default in the Maven lifecycle.

None of the solutions above worked for me straight away. So I followed these steps:
Add in pom.xml:
<properties>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.source>1.8</maven.compiler.source>
</properties>
Go to Project Properties > Java Build Path, then remove the JRE
System Library pointing to JRE1.5.
Force updated the project.

The below steps work for me like charm! so thought to share with everyone.
These are the lines i added in the pom.xml file to work with a basic project. I am using Java 12 (you can replace yours 11, 10, 1.8 etc).
<properties>
<maven.compiler.source>12</maven.compiler.source>
<maven.compiler.target>12</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<release>12</release>
</configuration>
</plugin>
</plugins>
</build>
After changing the pom file please reload your project so that IDE can download/fetch the plugin to the project. (For IntelijIDEA: Right-click on pom.xml -> Go to maven -> Reload project).
please make sure to configure the desire version in your IDE as well.

if you are using IntelliJ idea maven build.

Consider the alternative:
<properties>
<javac.src.version>1.8</javac.src.version>
<javac.target.version>1.8</javac.target.version>
</properties>
It should be the same thing of maven.compiler.source/maven.compiler.target but the above solution works for me, otherwise the second one gets the parent specification (I have a matrioska of .pom)

For NetBeans IDE, changing project properties - (Jersey Service) - Categories > Sources >
Selected 'Source/Binary Format' as 1.8.

openshift: maven compiler error : Base64 can not find the symbol

I am deploying webapp to the openshift cloud.
While compiling the resources by maven automatically after deploying, it shows Base64: symbol not found
However when I maven compile it on my Pc, their are no errors and build is successfull. I tried to change Base64 from java.util to apache.commons.codecs. The error is still there while deploying and it successfully runs at my local machine
Following is the pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<inherited>true</inherited>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
<dependencies>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.4</version>
</dependency>
Should I place the commons-codec jar in WEB_INF directory. i read the solution somewhere but was not sure about it.
please suggest a solution. Thank you
</dependencies>

My guess is that you're using JDK 8 on your machine, but JDK 7 where the error is happening as java.util.Base64 is only available since Java SE 8.
I recommend to use the same Java version on both machines.
Otherwise you should consider cross-compiling. Just setting the source and target level is not enough, as you can see, as you're still able to call new APIs.

Unable to locate Source XRef to link to

I have a big Maven project that uses the PMD plugin for code quality checks.
since I started using the PMD plugin i get the following warning message:
[WARNING] Unable to locate Source XRef to link to - DISABLED
I googled and found that i need to implement the JXR plugin.
So I added the following to the main pom.xml file.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>2.3</version>
</plugin>
It doesn't really change anything.
Any ideas what I need to change in order to resolve this warning message?
output of mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 10:44:56+0200)
Maven home: /usr/share/maven-bin-3.0
Java version: 1.7.0_05, vendor: Oracle Corporation
Java home: /usr/lib64/icedtea7/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "3.5.2-gentoo", arch: "amd64", family: "unix"
thanks!

You should add the maven-jxr-plugin to the reportingPlugin section.
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>3.3.0</version>
</plugin>
</plugins>
</reporting>
Re run it and enjoy.
BTW, maybe you'll need to run once the jxr:jxr goal to first generate some file that will be used by pmd.

Mind there is also the ability to disable the xref feature by adding
<configuration>
<linkXRef>false</linkXRef>
</configuration>
to the maven-pmd-plugin plugin. This resolves the warning without making the build even longer due to running an additional reporting plugin. E.g. if you run your builds in Jenkins, the Jenkins PMD plugin can take care of relating PMD warnings to source code, there is no need to run another Maven plugin for this.

You should add the maven-jxr-plugin and run the jxr:jxr goal before the site lifecycle if the maven-jxr-plugin is added as a plugin like in your case:
clean jxr:jxr site
Otherwise you should add it as a report if you want it to work with mvn site. Take a look at the JXR Usage Documentation :
JXR Usage

It is way easier to configure it this way and not tie it to the site phase.
Then, it is as simple as mvn test.
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
<configuration>
<outputDirectory>target/surefire-reports</outputDirectory>
<linkXRef>false</linkXRef>
</configuration>
</plugin>
</plugins>