We Keep Coding

Test the packaged artifact with Maven failsafe

In my Maven/Java project, I want to make sure that I always get the loading of resources right -- some can be always fetched as Files, others get packaged into the final .jar and have to be fetched as streams.
I now would have thought that this is the ideal task for the Maven failsafe plugin: I simply JUnit-test the affected methods in the Unit tests (means, that the tests are run using the classes lying in the classes folder) using surefire and in the integration tests (means, the tests are run using the classes packed into the jar) using surefire.
But when I make a demo project that throws an Exception when run from the .jar and doesn't when run from Eclipse, both the unit tests and the integration tests calling the method do not throw an exception, means that failsafe doesn't use the packaged jar at all.
How can I tie it to the jar artifact only?
My pom.xml:
<project ...>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<configuration>
<mainClass>packagingTest.MainClass</mainClass>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.12</version>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>integration-test</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
... Dependency to JUnit ...
</project>

Spring Boot control target JAR file name

My Spring Boot project has build description:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.18.1</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>2.18.1</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring-boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>com.app.MainClass</mainClass>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
I want my JAR file name to be app-1.0-SNAPSHOT.jar in one branch and 1.0-RELEASE.jar in another, controlled by Jenkins (using some kind of mvn settings or JVM argument such as -D..
Can I do this?

So simple, In one branch, you have pom.xml with
<build>
<finalName>app-1.0-SNAPSHOT</finalName>
</build>
In other branch, you have pom.xml with
<build>
<finalName>1.0-RELEASE</finalName>
</build>

You can propagate the version of the project to your build name like this:
<build>
<finalName>app-${project.version}</finalName>
</build>
or the version of your parent project if you have one:
<build>
<finalName>app-${parent.version}</finalName>
</build>
Then you would keep track of you project version rather than the build name.
However, note that managing the build verson in SCM using branches is a pain in the neck and error prone. It is rather recommanded that your code repository woud be agnostic of your build version.
A possible alternative would be to use some release management tool, like maven release plugin, or even more simple maven version.
Example:
Here I'll give and example using maven verion.
Say you're using SCM tool (it could be git) and a build factory (like Jenkins or any other tool). Say you have a job to build and deploy snapshots and another one for releases.
In the snapshot job, you can set-up a pre-build task with the following maven target:
versions:set -DnewVersion=app-1.0-SNAPSHOT
and the following in the release job:
versions:set -DnewVersion=app-1.0-RELEASE
Now doing this is OK, because you are only doing it locally and never have to manage the build version in your code.
Now, you can tag your (release) version after having applied maven version and build successfuly (hopefuly including unit, integration and functional tests). This way you may keep track exactly of the code that has been deployed on each release.
Tip!! Space is money! Do yourself a favour: clean your snapshot repository regularly. Creating a job that does so every once in a while shouldn't be to difficult.

You can specify the artefact-name with the maven boot plugin:
In this case, it will be NewJarName.jar
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>repackage</id>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<finalName>NewJarName</finalName>
</configuration>
</execution>
</executions>
</plugin>

How can I make a Maven module only go until the test phase when the parent gets deployed?

I'm working on a multi-module project. One of our module is a tests project, which tests the other modules.
First question: is it a good pratice?
The Maven build lifecycle phases are:
validate
compile
test
package
integration-test
verify
install
deploy
When installing or deploying the parent module, how can I make the tests module only go until the test phase, i.e. to skip package and following phases? Since the only purpose of this module is to test the other ones.

I assume that it is a jar project. Look at the Plugin Bindings for Default Lifecycle Reference.
Bind the default executions of the maven-jar-plugin, maven-install-plugin and maven-deploy-plugin plugins to the none phase in the pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
<executions>
<execution>
<id>default-deploy</id>
<phase>none</phase>
</execution>
</executions>
</plugin>

Maven Javadoc aggregate-jar plugin fails because of unresolved dependencies

I have multi-module Maven project in which I run the maven-javadoc-plugin to generate javadoc. In my parent pom.xml I have defined the plugin build as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<!-- Default configuration for all reports -->
</configuration>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate-jar</goal>
</goals>
<phase>install</phase>
<configuration>
<!-- Specific configuration for the aggregate report -->
</configuration>
</execution>
</executions>
</plugin>
When I run mvn clean install the build fails with unresolved dependencies, but I see the following warning:
[WARNING] The dependency:
[my.application:my-module:jar:1.7.1] can't be resolved but
has been found in the reactor (probably snapshots). This dependency
has been excluded from the Javadoc classpath. You should rerun javadoc
after executing mvn install.
As I am currently building my-module 1.7.1, I would assume Maven to detect this and run the aggregate-jar after building my-module, but for some reason it expects my-module to already be installed in a repo.
My Maven version is 3.0.4. Please keep in mind that I am new to Maven builds so this may be a very simple question, but I was not able to find any answer.
Some observations:
The build succeeds if I first run mvn clean install without the javadoc plugin aggregate-jar goal
The javadoc plugin aggregate goal runs fine.
This bug refers exactly to my issue, but should have been solved in Maven 3 (2010)

I run this command in my parent pom and this is how I do it without issues:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.1</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>aggregate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
When I want to generate the docs, I do mvn javadoc:aggregate

Maven read .properties to use in pom.xml

Im trying to get the properties-maven-plugin to read from my .properties file. Flyway (which im trying to use the properties for) just keeps throwing errors about the db url being malformed, but works if i set the values within the pom.xml itself, rather than using the properties read from file.
Im using eclipse with the m2e plugin.
plugin config to read from .properties
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>src/main/resources/config.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
Flyway config where the properties are being used
<plugin>
<groupId>com.googlecode.flyway</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>flyway:migrate</goal>
</goals>
</execution>
</executions>
<configuration>
<driver>${db.driver}</driver>
<url>${db.url}</url>
<user>${db.user}</user>
<password>${db.password}</password>
</configuration>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.26</version>
</dependency>
</dependencies>
</plugin>
config.properties located in /src/main/resources/
# Database details
db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://localhost:3306/dbname
db.user=username
db.pass=password
Ive tried looking through several other stackoverflow threads but none of the solutions seem to work. I'm new to maven and the whole thing seems to be throwing me, anyone got a light to shed?

There are basically two ways you can execute the Flyway migrate goal:
As part of a lifecycle phase: You have configured the Flyway plugin to be executed during the compile phase. That means you can just enter mvn compile and Flyway will be executed along with all other goals that are part of that lifecycle phase and all previous phases. Everything works fine, except you have a slight misconfiguration: The goal must not be prefixed. In order to fix this you have to provide the goal without prefix:
<goals>
<goal>migrate</goal>
</goals>
Now the execution works. Flyway gets all parameters from the properties-maven-plugin because it is executed in a previous phase.
Direct invocation: If you execute Flyway with mvn flyway:migrate, the plugin is invoked independent of any lifecycle phases. Since no phase is executed, the properties-maven-plugin is also not executed because it relies on the initialize phase - which effectively doesn't set any parameters. That's why Flyway complains about missing parameters.
Solution:
If you want the properties-maven-plugin to work together with Flyway you have to execute Flyway as part of a lifecycle. If you don't want to invoke it with every compile phase, you could create a separate profile and only run this profile whenever you need a Flyway migration with mvn compile -PflywayMigration:
<profiles>
<profile>
<id>flywayMigration</id>
<build>
<plugins>
<plugin>
<groupId>com.googlecode.flyway</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>migrate</goal>
</goals>
</execution>
</executions>
<configuration>
<driver>${db.driver}</driver>
<url>${db.url}</url>
<user>${db.user}</user>
<password>${db.password}</password>
</configuration>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.26</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
</profiles>