We Keep Coding

Maven 3: How to exclude generated sources from Xlint check?

We only allow java source code without Xlint errors. However, when sources are generated by third party tools, this is not practical. Examples of generated sources in our use-case are: JFlex, JavaCC, JAXB and annotation processors.
So the question is: how to exclude the generated sources from the Xlint checks? (see current configuration below)
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration combine.self="override">
<source>${java.version}</source>
<target>${java.version}</target>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
<!-- Since JDK1.3 javac ignores any optimization flags -->
<optimize>true</optimize>
<debug>false</debug>
</configuration>
<executions>
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<!-- everything in target/generated-sources/** should be excluded from this check -->
<compilerArgs>
<arg>-Xlint:all,-rawtypes</arg>
</compilerArgs>
</configuration>
</execution>
</executions>
</plugin>

There is no direct configuration in the maven-compiler-plugin to do that. The parameters passed are for the whole execution, so passing -Xlint:all would apply to all sources to compile.
The solution here is to compile it in two pass: first pass would compile the generated sources without any lint check, and the second pass would compile your project sources (that might depend on the generated classes). Again, the Compiler Plugin doesn't offer a way to specify a path to sources to compile: it compiles all of the sources of the current Maven project.
You have 2 solutions: use 2 executions of the Compiler Plugin with includes/excludes or split this in 2 modules.
Include/Exclude
The idea is to have 2 executions: one that would exclude your main classes (and compile the generated ones), while the other execution would include them. Note that the inclusion/exclusion mechanism works on the fully qualified name of the classes, not the directory structure; so you can't exclude src/main/java.
Assuming all of your main java source files are under the my.package package, you can have:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
</configuration>
<executions>
<execution> <!-- this execution excludes my main sources under my.package -->
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration> <!-- no lint check -->
<excludes>
<exclude>my/package/**/*.java</exclude>
</excludes>
</configuration>
</execution>
<execution> <!-- this execution includes my main sources under my.package -->
<id>compile-main</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration> <!-- adds lint check -->
<includes>
<include>my/package/**/*.java</include>
</includes>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
<compilerArgs>
<arg>-Xlint:all,-rawtypes</arg>
</compilerArgs>
</configuration>
</execution>
</executions>
</plugin>
This works because the first execution overrides the default-compile execution that Maven launches automatically on the compile phase, so it makes sure that the generated classes are compiled first.
Using two modules
As such, you need to split this in 2 modules, where the first module would generate the sources and compile them, while the second module would depend on the first one. Create a multi-module Maven project and have a parent my-parent with 2 modules:
<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>my.groupId</groupId>
<artifactId>my-parent</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<modules>
<module>my-generating-module</module>
<module>my-module</module>
</modules>
</project>
You could add a <pluginManagement> block here to define default configuration for all the modules using it, like <source> and <target>.
The first module, my-generating-module, is responsible for generating and compiling the sources without any lint check. By default, showWarnings is false so you can keep the default configuration.
Then, in the second module, you can have a dependency on this first one, adding the lint check. Since this will only compile your project sources (the classes generated were already compiled and packaged in the other module), you won't have any warnings for those.

How to set additional Class-Path entries in manifest with onejar Maven plugin?

Is there a way to add an arbitrary classpath entry to a JAR file manifest using onejar-maven-plugin?
I found the way to configure maven-jar-plugin to do this, but it appears that there is no such option for onejar-maven-plugin.
This is not done to find additional classes (otherwise why use the onejar plugin, right?), but rather to locate a configuration file that must be external to the JAR.
Is there a direct solution or a workaround for this?

Is the usage of the one-jar plugin really required?
You can achieve the same goal (packaging in one single jar your application AND all the required dependencies, including transitive ones, AND add configuration for Class-Path AND using a more stable/standard plugin) applying the following approach:
Configure the Class-Path entry in your application Jar using the Maven Jar Plugin and the approach you mentioned in the question
Use the Maven Assembly Plugin to package one single JAR including dependencies, as explained here, in another stackoverflow question/answer.
An example of one-jar executable file (without using the one-jar plugin) could be as following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<!-- your further configuration here -->
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>com.sample.MainApp</mainClass>
<!-- your further configuration here -->
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
If you need to further play with classpath and Maven, I would suggest to also check this question here on stackoverflow.

Adding arbitrary manifest entries is possible in 1.4.5:
<plugin>
<groupId>org.dstovall</groupId>
<artifactId>onejar-maven-plugin</artifactId>
<version>1.4.5</version>
<executions>
<execution>
<configuration>
<manifestEntries>
<Build-Status>Yes</Build-Status>
</manifestEntries>
</configuration>
<goals>
<goal>one-jar</goal>
</goals>
</execution>
</executions>
</plugin>
The onejar-maven-plugin project doesn't seem to be in active development anymore, so you might want to switch to other solutions (e.g. maven-assembly-plugin) eventually.
The plugin is not available on Maven Central. Someone else put up a version of it to Maven Central with a different group ID.

Additional libraries can be added to the classpath at the time of launch.
The property one-jar.class.path can be used
one-jar.class.path
Extra classpaths to be added to the execution environment. Use platform independent path separator '|'
Example: --one-jar.class.path="./lib/two.jar|/opt/lib/three.jar"
Source: http://one-jar.sourceforge.net/index.php?page=details

Maven aggregation build uses different java than building a child module on its own

I noticed an unexpected behavior. I have an aggregation POM for the purposes of aggregated goals execution.
When I execute the build task, the modules included in aggregation POM have their javadoc generated. The javadoc generation is defined in parent POM (not the same as aggregation POM) like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
The child module has its own POM, in which an aspectJ plugin is defined like this: (this is how the build tag actually looks like as a whole in the child POM:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.6</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<complianceLevel>1.7</complianceLevel>
<verbose>true</verbose>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
<dependencies>
</dependencies>
</plugin>
</plugins>
</build>
Now, when I run the aggregation build, it generates javadocs with Java 1.8 (there is no mention about which java to use in aggregation POM):
Constructing Javadoc information...
Standard Doclet version 1.8.0
Building tree for all the packages and classes...
...
12 errors
16 warnings
But when I run build just on the child module, it will use Java 1.7.0_45
Constructing Javadoc information...
Standard Doclet version 1.7.0_45
Building tree for all the packages and classes...
...
2 warnings
Why this inconsistency? I would expect that the build should work the same. Am I doing something wrong? How does one configure the aggregation build to use the configuration of the child module (with its POM), which to me seems the way which should be default.
My assumption is that aggregation build is the same thing as running "install" goal on each child module manually as if on a seperate project. Is this assumption wrong? (seems like it is, since this behaviour) If yes, what is actually happening?
If information are missing (parts of pom configurations) please comment.

Maven build two copies: one with lib shaded in, one without

I have a maven project that uses the maven-shade plugin to bundle a common-code-library jar into several distributed software plugins I make.
These plugins are all for the same main application - so when someone uses more than one plugin, it becomes a problem because each plugin has a copy of the shaded lib and they're not always using the same version.
I'm not sure how to resolve this. Is there a way I can configure maven to make two builds - one with the library shaded in, and one without? For the one without, we'll provide only one copy of the library needed as a separate resource.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.1</version>
<configuration>
<artifactSet>
<includes>
// our common lib
</includes>
</artifactSet>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

Just change the finalName configuration property of shade plugin. See here. It's just overwriting your original package. If you change the output name both packages will be left.
You can use something like
<configuration>
...
<finalName>${build.finalName}-nodep.jar</finalName>
</configuration>
You can alternatively change outputFile or outputDirectory
Also if you want to preserve original artifact name but use classifier set shadedArtifactAttached to true.

The solution to my issue is to relocate the classes I'm shading, so they won't load copies found in other jars:
http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

maven checkstyle unable to find where to insert the includes configuration

We have a maven project where I use a checkstyle plugin in the build process and we are very fond of checkstyle. Anyway recently we need to insert web services to our project. The web services classes are not compatible with checkstyle so we want to exclude them when building. So as a way of exclude we want to specify the folders to be included.
I have come across maven.checkstyle.includes and sourceDirectory of checkstyle plugin. But I could not be able to figure out how to use them in pom.xml.
Anyone have an idea?
Here is my checkstyle section of pom.xml
<build>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<failsOnError>true</failsOnError>
<consoleOutput>true</consoleOutput>
<configLocation>sample_config.xml</configLocation>
<sourceDirectory>${maven.checkstyle.includes}</sourceDirectory>
</configuration>
</plugin>
...
</build>

<excludes>my/package/**/*</excludes>
Add this to your configuration section. These are ant style patterns and you can give the plugin multiple patterns by separating them with a comma.