Using JDK8 to compile for target JRE7 - java

Up until today I was under the impression that -target argument on the compile would be enough to ensure that my application would execute on JRE7 even if compiled with a JDK8 javac.
I soon got wiser as I learned about how Sun/Oracle changes method signatures from one release to another.
My aim is - using JDK8 tool chain - to create a binary that will execute with both JRE7 and JRE8. Our build farms where I work are multi-OS, meaning some are Windows, some are Solaris, etc. I cannot predict beforehand where my application is going to build.
I understand the recommended solution is to use -Xbootclasspath on the compile step. I'm using Maven so I'll need something like this:
<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>
<compilerArguments>
<bootclasspath>XXXX</bootclasspath>
</compilerArguments>
</configuration>
</plugin>
</plugins>
</build>
What I don't understand is how to set XXXX so that my application will build anywhere and not just on my own workstation. Essentially I would like XXXX to be an artifact or a dependency if you like. I do not have control over target build machines but I can upload third party artifacts to our corporate Maven repo. How to solve this issue?
The other problem I see is that XXXX is really a list. It is not a single jar. (as far as I understand - to be safe - it is really the value of sun.boot.class.path from the target JRE, meaning it is more than just rt.jar as some literature seems to suggest). How do I set XXXX in a way so that it is OS independent, given that ";" is used as list item separator on Windows whereas ":" is used on Unix/Linux. How to solve that ?


You can try profiles
<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<bootclasspath>xxx</bootclasspath>
</properties>
</profile>
<profile>
<id>win</id>
<activation>
<os>
<family>Windows</family>
</os>
</activation>
<properties>
<bootclasspath>yyy</bootclasspath>
</properties>
</profile>
</profiles>


I suggest not to cross-compile, but to actually use the JDK you want to build against.
If this JDK version differs from the rest of your project, then use the Maven Toolchain Plugin.


Assuming that the maven itself runs under JDK 8 but the intention is to compile a module to be compatible with JDK 7.
The proper cross-compilation requires that the target JDK is present. Consider the following approach to configure cross-compilation for a particular Maven module:
Allow compilation even when the target JDK is not present.
Automatically use cross-compilation when the target JDK is present.
The Maven is unable to detect the presence of other JDKs by itself, so you will have to define the environment property (JDK7_HOME in the example below) which will trigger the cross-compilation profile and provide the base path for bootclasspath configuration.
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<!--
the base config should generate class files
with the proper version number
even in the absence of cross-compilation JDK
-->
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>cross-compile-jdk7</id>
<activation>
<property>
<!--
the proper cross-compilation is triggered
when the cross-compilation JDK is really present
-->
<name>env.JDK7_HOME</name>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<!--
the advanced config not only generates class files
with the proper version number
but also uses correct bootclasspath
-->
<source>1.7</source>
<target>1.7</target>
<!--
forking is required for when changing bootclasspath
-->
<fork>true</fork>
<!--
the following monstrosity is the most paranoid way
to get correct file and path separators
this particular example includes rt.jar and jsse.jar
from the target JDK
-->
<compilerArgs>
<arg>-bootclasspath</arg>
<arg>${env.JDK7_HOME}${file.separator}jre${file.separator}lib${file.separator}rt.jar${path.separator}${env.JDK7_HOME}${file.separator}jre${file.separator}lib${file.separator}jsse.jar</arg>
</compilerArgs>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>

Related

How to compile in debug mode using maven without making changes to pom.xml?

I am trying to run some vulnerability scans(Veracode) on a spring boot application. However, the scan provider suggests running the scans with binaries compiled in debug mode using the following in pom.xml file.
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<debug>true</debug>
<debuglevel>lines,vars,source</debuglevel>
</configuration>
</plugin>
</plugins>
</build>
However, we use the same pom.xml for production deployment where we don't want debug level jars.
Is there a way to create debug jars by passing some argument to the mvn command?

You can use profiles.
<profiles>
<profile>
<id>debug</id>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<debug>true</debug>
<debuglevel>lines,vars,source</debuglevel>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profile>
Profiles are activated in the mvn command, e.g., mvn ... -Pdebug.

I think it is possible to set the arguments in the command line with -D like this:
mvn compile -Dmaven.compiler.debug=true -Dmaven.compiler.debuglevel=lines,vars,source

Maven Build Profile Activation

I know there are some related topics but still I can't understand how to do it.
I'm learning maven and currently in process of creating build profiles. I want maven to auto detect the currently installed java version on my machine. Let's say I'm working in our office which uses (jdk7) or home (jdk8), I want the <source> and <target> elements in maven-compiler-plugin pom.xml to auto detect the java -version regardless of environment (office / home). I've read about activation but can't perfectly understand the purpose.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>${jdk.version}</source>
<target>${jdk.version}</target>
</configuration>
</plugin>
</plugins>
</build>

Hi I don't think you can have your build, environment aware automatically, just using the defaults, you need some help of profiles and their activation capability see here. What you can do is introduce 2 different profiles, in each profile you can define the JDK you want, and it will be activated for your if present, then you can configure either the compiler plugin with different source /target or, just set different values for a a property that is going to indicate the java version. Example:
<profiles>
<profile>
<id>java8</id>
<activation>
<jdk>1.8</jdk>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>java7</id>
<activation>
<jdk>1.7</jdk>
</activation>
<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>
</plugins>
</build>
</profile>
</profiles>
Hope that helps :)

For Java 9 the following profiles can be used.
<profiles>
<profile>
<id>java8</id>
<activation>
<jdk>1.8</jdk>
</activation>
(...)
</profile>
<profile>
<id>java9</id>
<activation>
<jdk>9</jdk>
</activation>
(...)
</profile>
</profiles>

You will want to declare two mutually exclusive profiles, one for jdk7 builds and one for jdk8 builds. Each profile declaration has two important parts:
The activation element is like a conditional, and is nested within . Is your profile on or off? You will want to set up the jdk based activation. Example for your jdk7 profile:
<activation>
<jdk>1.7</jdk>
</activation>
Next you'll want to define the property or properties that get set when your profile is active. Example for jdk7:
<properties>
<jdk.version>1.7<jdk.version>
</properties>
Both of those sections get combined with an id element (e.g. <id>jdk7</id>) and nested within a profile element.
If you have any problems getting the jdk detection activation to work, I'd suggest experimenting with an explicit trigger, such as invoking maven with mvn -P jdk7.
From the sounds of it, you want a jdk7 and a jdk8 profile to be defined within your pom.xml. But another option is to have a single profile which is always on, but define the jdk.version property for the profile differently inside of your ~/.m2/settings.xml file. The settings.xml file at the office would have the jdk7 properties; at home it would have jdk8.
http://maven.apache.org/guides/introduction/introduction-to-profiles.html

Change java SDK version in maven eclipse project

I have created new maven java project in eclipse by clicking File->New->Other->Maven->New Project. I found that projects is using java 1.5. In my PC exist only java 1.4 and java 8. I need to compile project using java 1.4 JDK. I go to Project->Properties-> JRE System Library and change to java 1.4. When I run main class I have error:
java.lang.UnsupportedClassVersionError: arr/ff (Unsupported major.minor version 49.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
How to make project java 1.4 compatible?

First, I'd define a property to control the value. Something like,
<properties>
<java.version>1.4</java.version>
</properties>
And then add a build stanza, like
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<verbose>true</verbose>
<fork>true</fork>
<debug>false</debug>
<source>${java.version}</source>
<target>${java.version}</target>
</configuration>
</plugin>
</plugins>
</build>

Specify source and target Java version by this way:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.5</source>
<target>1.4</target>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
Read offical document.
Read about Java version compatibility.

Usually IDEs use maven pom.xml file as a source of project configuration. Changing the compiler settings in the IDE not always has effect on the maven build. The best way to keep a project always manageable with maven is edit the pom.xml files and instruct the IDE to sync with maven.
Configure the maven compiler plugin in the pom.xml
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.4</target>
</configuration>
</plugin>
</plugins>
...
OR Set these properties (always in the pom)
<properties>
<maven.compiler.source>1.5</maven.compiler.source>
<maven.compiler.target>1.4</maven.compiler.target>
</properties>

Different ways to override java version specified in parent pom

I'm using a parent pom which establishes java version to 1.5. In my concrete project I use 1.6 so I was changing the compiler version in eclipse each time I did a Maven Update.
Looking for a solution to this I found some solutions involving overriding the behavior of the parent pom in the child one.
My question is if there are any differences between them and if so, which option should I use. The options I found (perhaps there are more) are:
In properties tag: <app.java.version>1.6</app.java.version>
In properties tag: <jdk.version>1.6</jdk.version>
In configuration tag: <source>${jdk.version}</source>
I'm very new to Maven. Thanks in advance.

You definitely want to go with:
<properties>
<maven.compiler.source>1.6</maven.compiler.source>
<maven.compiler.target>1.6</maven.compiler.target>
</properties>
It is the de facto standard Maven property for setting up Java version and it's used not only by maven-compiler-plugin but also by other standard Maven plugins (including reporting ones), so this applies your Java version globally, not only for compiling classes.

Properties are just properties, which do not mean much unless you use them somewhere.
The important thing is that you set the version in the maven-compiler-pluginconfiguration:
<properties>
<jdk.version>1.6</jdk.version>
</properties>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>${jdk.version}</source>
<target>${jdk.version}</target>
</configuration>
</plugin>
</plugins>

If your parent pom uses 1.7 jdk and you want child pom to use 1.6 java version. combine.self="override" is important use following code:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration combine.self="override">
<verbose>true</verbose>
<fork>true</fork>
<executable>/usr/lib/jvm/java-1.6.0-openjdk-amd64/bin/javac</executable>
<compilerVersion>1.6</compilerVersion>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>

Maven is not working in Java 8 when Javadoc tags are incomplete

Since I use Maven I have been able to build and install in my local repository projects that have incomplete Javadoc tags (for example, a missing parameter).
However, since I migrated to Java 8 (1.8.0-ea-b90) Maven is absolutely strict about missing documentation tags and show me lots of Javadoc errors related to Javadoc problems when I try to build or install a project where the Javadoc is not "perfect". Some of the projects I am trying to compile and install in my local repository are third party projects from which I do not have control. So the workaround of just fixing all the Javadocs in all these projects does not seem to be feasable in my scenario.
This is a small part of the output I see when I execute mvn clean package install in my project:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.026s
[INFO] Finished at: Mon Apr 08 21:06:17 CEST 2013
[INFO] Final Memory: 27M/437M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:jar (attach-javadocs) on project jpc: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - /Users/sergioc/Documents/workspaces/heal/jpc/src/main/java/org/jpc/engine/prolog/PrologDatabase.java:10: error: #param name not found
[ERROR] * #param terms the terms to assert
[ERROR] ^
[ERROR] /Users/sergioc/Documents/workspaces/heal/jpc/src/main/java/org/jpc/engine/prolog/PrologDatabase.java:11: warning: no description for #return
[ERROR] * #return
[ERROR] ^
The Javadoc Maven plugin is configured like this in my POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
As I said before, everything is working fine if I go back to Java 7.
Maybe is this a bug related to Maven running in Java 8?
How could I make it work (i.e., being able to build the Javadoc of the project and install its code in my local repository) with Java 8?
I have tested with both Maven 3.0.3 and 3.0.5 in OSX.
UPDATE:
If I change my Javadoc plugin configuration with <failOnError>false</failOnError> (thanks Martin):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Then the project is installed in my local repository. However, the Javadoc JAR is still not generated.
A fragment of the output I see in the console with this new configuration is:
[ERROR] MavenReportException: Error while creating archive: Exit
code: 1 - /Users/....java:18: warning: no #param ... Command line
was: /Library/Java/Home/bin/javadoc #options #packages
Refer to the generated Javadoc files in
'/Users/sergioc/Documents/workspaces/heal/minitoolbox/target/apidocs'
dir.
at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeJavadocCommandLine(AbstractJavadocMojo.java:5043)
at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1990)
at
org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:181)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at
org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at
org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:491) at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Any workaround about how to build the sources, install the project and generate the Javadoc JAR in one step as it was working with Java 7?

The best solution would be to fix the javadoc errors. If for some reason that is not possible (ie: auto generated source code) then you can disable this check.
DocLint is a new feature in Java 8, which is summarized as:
Provide a means to detect errors in Javadoc comments early in the
development cycle and in a way that is easily linked back to the
source code.
This is enabled by default, and will run a whole lot of checks before generating Javadocs. You need to turn this off for Java 8 as specified in this thread. You'll have to add this to your maven configuration:
<profiles>
<profile>
<id>java8-doclint-disabled</id>
<activation>
<jdk>[1.8,)</jdk>
</activation>
<properties>
<javadoc.opts>-Xdoclint:none</javadoc.opts>
</properties>
</profile>
</profiles>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<additionalparam>${javadoc.opts}</additionalparam>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.3</version>
<configuration>
<reportPlugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<additionalparam>${javadoc.opts}</additionalparam>
</configuration>
</plugin>
</reportPlugins>
</configuration>
</plugin>
</plugins>
</build>
For maven-javadoc-plugin 3.0.0+:
Replace
<additionalparam>-Xdoclint:none</additionalparam>
with
<doclint>none</doclint>

The easiest approach to get things working with both java 8 and java 7 is to use a profile in the build:
<profiles>
<profile>
<id>doclint-java8-disable</id>
<activation>
<jdk>[1.8,)</jdk>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<additionalparam>-Xdoclint:none</additionalparam>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>

Here is the most concise way I am aware of to ignore doclint warnings regardless of java version used. There is no need to duplicate plugin configuration in multiple profiles with slight modifications.
<profiles>
<profile>
<id>doclint-java8-disable</id>
<activation>
<jdk>[1.8,)</jdk>
</activation>
<properties>
<javadoc.opts>-Xdoclint:none</javadoc.opts>
</properties>
</profile>
</profiles>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<executions>
<execution>
<id>attach-javadocs</id> <!-- The actual id should be apparent from maven output -->
<configuration>
<additionalparam>${javadoc.opts}</additionalparam>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
Tested on oracle/open jdk 6, 7, 8 and 11.

The shortest solution that will work with any Java version:
<profiles>
<profile>
<id>disable-java8-doclint</id>
<activation>
<jdk>[1.8,)</jdk>
</activation>
<properties>
<additionalparam>-Xdoclint:none</additionalparam>
</properties>
</profile>
</profiles>
Just add that to your POM and you're good to go.
This is basically #ankon's answer plus #zapp's answer.
For maven-javadoc-plugin 3.0.0 users:
Replace
<additionalparam>-Xdoclint:none</additionalparam>
by
<doclint>none</doclint>

Add into the global properties section in the pom file:
<project>
...
<properties>
<additionalparam>-Xdoclint:none</additionalparam>
</properties>
The common solution provided here in the other answers (adding that property in the plugins section) did not work for some reason. Only by setting it globally I could build the javadoc jar successfully.

I don't think just turning off DocLint is a good solution, at least not long term. It is good that Javadoc has become a bit more strict so the right way to fix the build problem is to fix the underlying problem. Yes, you'll ultimately need to fix those source code files.
Here are the things to look out for that you could previously get away with:
Malformed HTML (for example a missing end-tag, un-escaped brackets, etc)
Invalid {#link }s. (same goes for similar tags such as #see)
Invalid #author values. This used to be accepted : #author John <john.doe#mine.com> but not so anymore because of the un-escaped brackets.
HTML tables in Javadoc now require a summary or caption. See this question for explanation.
You'll simply have to fix your source code files and keep building your Javadoc until it can build without a failure. Cumbersome yes, but personally I like when I have brought my projects up to DocLint level because it means I can be more confident that the Javadoc I produce is actually what I intend.
There's of course the problem if you are generating Javadoc on some source code you've not produced yourself, for example because it comes from some code generator, e.g. wsimport. Strange that Oracle didn't prepare their own tools for JDK8 compliance before actually releasing JDK8. It seems it won't be fixed until Java 9. Only in this particular case I suggest to turn off DocLint as documented elsewhere on this page.

Overriding maven-javadoc-plugin configuration only, does not fix the problem with mvn site (used e.g during the release stage). Here's what I had to do:
<profile>
<id>doclint-java8-disable</id>
<activation>
<jdk>[1.8,)</jdk>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<additionalparam>-Xdoclint:none</additionalparam>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.3</version>
<configuration>
<reportPlugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<additionalparam>-Xdoclint:none</additionalparam>
</configuration>
</plugin>
</reportPlugins>
</configuration>
</plugin>
</plugins>
</build>
</profile>

You could try setting the failOnError property (see plugin documentation) to false:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<failOnError>false</failOnError>
</configuration>
</execution>
</executions>
</plugin>
As you can see from the docs, the default value is true.

Since it depends on the version of your JRE which is used to run the maven command you propably dont want to disable DocLint per default in your pom.xml
Hence, from command line you can use the switch -Dadditionalparam=-Xdoclint:none.
Example: mvn clean install -Dadditionalparam=-Xdoclint:none

The configuration property name has been changed in the latest version of maven-javadoc-plugin which is 3.0.0.
Hence the <additionalparam> will not work. So we have to modify it as below.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<doclint>none</doclint>
</configuration>
</plugin>

I would like to add some insight into other answers
In my case
-Xdoclint:none
Didn't work.
Let start with that, in my project, I didn't really need javadoc at all. Only some necessary plugins had got a build time dependency on it.
So, the most simple way solve my problem was:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>

As of maven-javadoc-plugin 3.0.0 you should have been using additionalJOption to set an additional Javadoc option, so if you would like Javadoc to disable doclint, you should add the following property.
<properties>
...
<additionalJOption>-Xdoclint:none</additionalJOption>
...
<properties>
You should also mention the version of maven-javadoc-plugin as 3.0.0 or higher.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.0.0</version>
</plugin>

So, save yourself some hours that I didn't and try this if it seems not to work:
<additionalJOption>-Xdoclint:none</additionalJOption>
The tag is changed for newer versions.

Added below
JAVA_TOOL_OPTIONS=-DadditionalJOption=-Xdoclint:none
Into Jenkins job :
Configuration > Build Environment > Inject environment variables to the build process > Properties Content
Solved my problem of code building through Jenkins Maven :-)

I'm not sure if this is going to help, but even i faced the exact same problem very recently with oozie-4.2.0 version. After reading through the above answers i have just added the maven option through command line and it worked for me. So, just sharing here.
I'm using java 1.8.0_77, haven't tried with java 1.7
bin/mkdistro.sh -DskipTests -Dmaven.javadoc.opts='-Xdoclint:-html'

To ignore missing #param and #return tags, it's enough to disable the missing doclint group. This way, the javadoc will still be checked for higher level and syntax issues:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<doclint>all,-missing</doclint>
</configuration>
</plugin>
Note that this is for plugin version 3.0 or newer.

I'm a bit late to the party, but I was forced to search for workaround too, ended up here, and then found it.
Here's what works for me:-
export JAVA_TOOL_OPTIONS=-DadditionalJOption=-Xdoclint:none
And then start your Maven build, any Linux distribution build etc. Nice thing about it that it doesn't require Maven config files modification - I couldn't do that as my objective was to rebuild a bunch of Centos rpm packages, so had to go really deep.

In my case I was using a parent pom (not sure it was the real cause since I was running against the clock), maven 2.x and java 1.6 were used, for some reason above solutions didn't work, so I added the following profile and managed it to make it run:
<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>myapp</artifactId>
<packaging>war</packaging>
<name>myapp</name>
<version>0.0.1-SNAPSHOT</version>
<description>My App</description>
<parent>
<groupId>com.mycompany</groupId>
<artifactId>parent-artifact</artifactId>
<version>0.0.1</version>
</parent>
<profiles>
<profile>
<id>doclint-java6-disable</id>
<activation>
<jdk>[1.6,)</jdk>
</activation>
<properties>
<additionalparam>--allow-script-in-comments</additionalparam>
</properties>
</profile>
</profiles>
</project>

Below configuration worked for me
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<failOnError>false</failOnError>
</configuration>
</plugin>

Categories

Resources