Develop Reference

maven-surefire-plugin isn't working with profiles

I have profile configuration in my POM with surefire-maven-plugin & junit connection to run only specific tests by profile. For example:
mvn clean test -Pgroup1 --also-make -DfailIfNoTests=false
It works as expected with following versions:
<maven-surefire-plugin.version>2.22.1</maven-surefire-plugin.version>
<junit.version>4.12</junit.version>
But stops working normally when I try to upgrade them:
<maven-surefire-plugin.version>3.0.0-M5</maven-surefire-plugin.version>
<junit.version>4.13</junit.version>
In this case mvn test always run all tests as I wouldn't set profile in command line.
My config of profiles is:
<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include>**/unit/*Test.java</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>group1</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/unit/**</exclude>
</excludes>
<groups>com.Group1</groups>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>group2</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/unit/**</exclude>
</excludes>
<groups>com.Group2</groups>
</configuration>
</plugin>
</plugins>
</build>
</profile>
......................
</profiles>
Every test class has connected interface linked to profile:
#Category(Group1.class)
#RunWith(JUnitParamsRunner.class)
public class Group1Test {
Playing with 'default' profile and 'activeByDefault' property also gave me no result. Any ideas how to fix it?

I got this to work by using "executions" in both the default plugin and in the profile plugin (which is not, by the way, an override of the default one)
<project>
...
<build>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M8</version>
<executions>
<execution>
<id>default-test</id>
<phase>test</phase>
<goals><goal>test</goal></goals> <!-- REQUIRED -->
<configuration>
<enableAssertions>true</enableAssertions>
<systemPropertyVariables>
<log4j.debug>true</log4j.debug>
<client.test.url>http://localhost:8080/axis/services/MyService</client.test.url>
</systemPropertyVariables>
<excludes>
<exclude>**/TestAccountOp</exclude> <!-- Tomcat required - use the profile -->
<exclude>**/TestWsdl</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>myprofileid-testwithtomcat</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M8</version>
<executions>
<execution> <id>default-test</id> <phase>none</phase> </execution> <!-- Disable default Maven execution -->
<execution>
<id>myexecutionid-testwithtomcat</id>
<phase>test</phase>
<goals><goal>test</goal></goals> <!-- REQUIRED -->
<configuration>
<enableAssertions>true</enableAssertions>
<systemPropertyVariables>
<log4j.debug>true</log4j.debug>
<client.test.url>http://localhost:8080/axis/services/MyService</client.test.url>
</systemPropertyVariables>
<excludes>
<exclude>**/TestWsdl</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
...
</profiles>
</project>
In the profile, I removed the "default-test", otherwise the "excludes" were set from the default one, but that might have been before I moved the "configurations" into the "executions". You have to remember that "default-test" is active unless you disable it, but not using an "execution" in the main body did not work for me.
"default-test" is Maven's "id" for the one in the main body, so that is why I used that name in the "execution" in the main body.
I think you can get away with not bothering with the "phase" elements, because that's the default for the "test" goal, but I'm pretty sure that you need the goal.
Good luck!

Migrating standalone application to Spring Boot

I do have a standalone application that is started through a main method, which is based on the Spring Framework and uses JavaFX for the user interface.
At the moment there is one main class, which parses the command line arguments and depending on the outcome sets up the Spring configuration. There are three distinctive configurations:
Server (no user interface or server user interface)
Client (only user interface)
Standalone (server and client run in the same application
With the current approach I can decide on the Spring configuration, however with Spring Boot the application basically becomes the top level configuration.
This lead me to the conclusion, that I will need three distinctive Spring Boot applications. As the whole project is set up with Maven the main class is in one module that depends on all others. I also have the Maven build set up to create an executable jar, as well as an executable application.
If I have three different Spring Boot applications, would that mean that I need to put them in different modules?
Based on this build configuration:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>ch.sahits.game.OpenPatrician</mainClass>
<addClasspath>true</addClasspath>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>com.zenjava</groupId>
<artifactId>javafx-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>unix</id>
<activation>
<os><family>unix</family></os>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>com.zenjava</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<configuration>
<mainClass>ch.sahits.game.OpenPatrician</mainClass>
<verbose>true</verbose>
<bundler>linux.app</bundler>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build> </profile>
<profile>
<id>windows</id>
<activation>
<os><family>windows</family></os>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>com.zenjava</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<configuration>
<mainClass>ch.sahits.game.OpenPatrician</mainClass>
<verbose>true</verbose>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
<profile>
<id>build-installer</id>
<properties>
<native.output.dir>${project.build.directory}/jfx/native/${project.build.finalName}</native.output.dir>
<native.output.dir.app>${native.output.dir}/app</native.output.dir.app>
<native.app.jar>${native.output.dir.app}/${project.build.finalName}-jfx.jar</native.app.jar>
</properties>
<dependencies>
<dependency>
<groupId>ch.sahits.game</groupId>
<artifactId>OpenPatricianDisplay</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>com.zenjava</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>native</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>create zip archive</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo>Creating self-contained zip native</echo>
<zip destfile="${project.build.directory}/OpenPatrician-${project.version}-[OS]64.zip" basedir="${native.output.dir}" />
<echo>Creating self-contained executable jar</echo>
<zip destfile="${project.build.directory}/OpenPatrician-${project.version}.zip" basedir="${native.output.dir.app}" />
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Should I change to the Spring Boot way to create an executable Jar file, or would this approach still work?

Update/replacement for properties maven plugin?

I have a fairly old maven project that uses the plugin below to write a properties file (to my understanding). I am currently updating the project dependencies and found out that the providers services have been terminated.
Is there a more up to date way of doing this, an example pom.xml extract would be great!!!
Thanks,
Adam
<profiles>
<profile>
<id>tests</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>write-project-properties</goal>
</goals>
<configuration>
<outputFile>${project.build.outputDirectory}/appversion.properties</outputFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>

Ensure test jars are named correctly

I'm setting up our system to do dual building for different versions of java artifacts based on the jdk used. There are 4 jars to build: artifact, artifact-tests, artifact-sources, and artifact-test-sources. Here is the output of the build
[INFO] Installing /Users/carlos/workspace/svn/Libraries/artifact-name/trunk/pom.xml to /Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT.pom
[INFO] Installing /Users/carlos/workspace/svn/Libraries/path/artifact-name-1.0.8-SNAPSHOT-java6.jar to /Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT-java6.jar
[INFO] Installing /Users/carlos/workspace/svn/Libraries/path/artifact-name-1.0.8-SNAPSHOT-sources.jar to /Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT-sources.jar
[INFO] Installing /Users/carlos/workspace/svn/Libraries/path/artifact-name-1.0.8-SNAPSHOT-test-sources.jar to /Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT-test-sources.jar
[INFO] Installing /Users/carlos/workspace/svn/Libraries/path/artifact-name-1.0.8-SNAPSHOT-tests.jar to /Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT-tests.jar
You can see the main artifact is built with java6 and has the appropriate classifier. I'm assuming the test classifier is overwriting the java6 classifier, but I'm unsure. Is there a way to get it to be named explicitly for both tests and the jdk? Something like -1.0.8-SNAPSHOT-tests-java6.jar. I'de like to refrain from doing manual changes to the final.name if possible and just use stock functionality like I did for the main artifact.
Here are the relevant parts of the pom.
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>${maven.jar.version}</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.version}</version>
<configuration>
<source>${jdk.version}</source>
<target>${jdk.version}</target>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>${maven.source.version}</version>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>analyze</id>
<goals>
<goal>analyze-only</goal>
</goals>
<configuration>
<failOnWarning>true</failOnWarning>
<ignoreNonCompile>true</ignoreNonCompile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.4</version>
<!--<configuration>-->
<!--<skip>true</skip>-->
<!--</configuration>-->
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${jdk.version}</source>
<target>${jdk.version}</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>jar</goal>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<classifier>${jdk.version.display}</classifier>
</configuration>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>java6</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>1.6</jdk>
</activation>
<properties>
<jdk.version>1.6</jdk.version>
<jdk.version.display>java6</jdk.version.display>
</properties>
</profile>
<profile>
<id>java7</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>1.7</jdk>
</activation>
<properties>
<jdk.version>1.7</jdk.version>
<jdk.version.display>java7</jdk.version.display>
</properties>
</profile>
<profile>
<id>java8</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<jdk.version>1.8</jdk.version>
<jdk.version.display>java8</jdk.version.display>
</properties>
</profile>
</profiles>

The -sources, -tests and -test-sources JARs are themselves using classifiers. So e.g. in the case of sources, you would need to override the maven-source-plugin's <classifier> configuration option (see also Maven deploy + source classifiers). I doubt that doing this is well tested across all the tool sets that consume -sources artifacts. For example, will Eclipse still download the sources for your java6 classifier artifact if you call the classifier java6-sources? And what about the tests, test-sources and (if you need it later) javadoc classifiers—will you complicate your POM further to generate all of those differently as well? Perhaps you could make it all work, but rather than trod down that path, it would be easier to simply use two different artifactIds, one for java6 and one for java7, and leave classifiers out of the equation.

Maven multi module project with separate tests module - Code Coverage?

I have a maven multi module project.
root:
moduleA/ # no unit tests
moduleB/ # no unit tests
moduleC/ # no unit tests
tests/ # All unit tests, since depends on modules A, B and C
All tests are in single module called tests/ and all code is in separate modules.
Is there a way I can get code coverage?

There is a way to accomplish this. The magic is to create a combined jacoco.exec file and to do it in two steps. My pom:
<properties>
...
<jacoco.overall.exec>${maven.multiModuleProjectDirectory}/target/jacoco_analysis/jacoco.exec</jacoco.overall.exec>
</properties>
<build>
<pluginManagement>
<plugins>
...
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.8</version>
<configuration>
<destFile>${jacoco.overall.exec}</destFile>
<dataFile>${jacoco.overall.exec}</dataFile>
</configuration>
</plugin>
...
</plugins>
</pluginManagement>
</build>
<profiles>
<profile>
<id>runTestWithJacoco</id>
<activation>
<property>
<name>runTestWithJacoco</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>default-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<append>true</append>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>createJacocoReport</id>
<activation>
<property>
<name>createJacocoReport</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>default-report</id>
<phase>validate</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Add this to your parent pom and execute mvn clean install -DrunTestWithJacoco and than mvn validate -DcreateJacocoReport. Now you have the complete coverage of a class and it doesn't matter which test covered it. The magic is to use maven.multiModuleProjectDirectory to create a combined jacoco.exec file. This property is available since maven 3.3.1 and points to the folder where you started your maven build.

I don't think either of jacoco or cobertura is capable of reporting code coverage across modules. You may want to try instrumenting the compiled classes before running the test coverage report rather than relying on on-the-fly instrumentation.
See this jacoco maven goal to perform the offline instrumentation.

Since Jacoco version: 0.7.7, you can use report-aggregate.
Root pom.xml :
<project>
[...]
<build>
<plugins>
<!-- refer：https://prismoskills.appspot.com/lessons/Maven/Chapter_06_-_Jacoco_report_aggregation.jsp -->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.6</version>
<executions>
<execution>
<id>prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
<goal>report-aggregate</goal>
</goals>
</execution>
</executions>
</plugin>
<plugins>
</build>
[...]
<pluginManagement>
<plugins>
<!-- unit test plugin -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>3.0.0-M5</version>
</dependency>
</dependencies>
<configuration>
<argLine>${argLine} -Dfile.encoding=UTF-8</argLine>
</configuration>
</plugin>
</plugins>
</pluginManagement>
[...]
</project>
Sub-modules pom.xml:
<project>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include>[path]</include>
</includes>
</configuration>
</plugin>
</plugins>
[...]
</project>
If you use Jenkin, you can just use jacoco plugin and <goal>report</goal> without other new things.