We Keep Coding

What does a Maven Artifact means in a context of runnable jar project? [duplicate]

I have a project that consist of 3 different libraries. When I run install script it takes all libraries from repo and run mvn clean install on them. But this version of library already installed in repo. Is there a way to skip install phase if version in pom.xml equal version in my local repo.
I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.

You can bypass like this
-Dmaven.install.skip=true
<profiles>
<profile>
<id>skipInstall</id>
<activation>
<property>
<name>maven.install.skip</name>
<value>true</value>
</property>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
Last week Olivier Lamy patched this jira.
MINSTALL-73

Most maven plugins can be skipped by specifying something like:
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
you can also set up build profiles to set properties and use that to determine the value. for example, running the command: mvn -Pexample would select the "example" profile. The POM would then contain:
...
<properties>
<skip.install>false</skip.install>
...
</properties>
...
<profile>
<id>example</id>
<properties>
<skip.install>false</skip.install>
</properties>
</profile>
...
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>${skip.install}</skip>
</configuration>
</plugin>
...
Using these POM additions, the default behavior for the install plugin will be to perform its default goal, but if the example profile is selected, then the install plugin will skip its goal.

Using what I learned from the other answers, this was the cleanest result for me.
In my super pom I added a pluginManagement/plugin to disable default-install and default-test phases when the property deployOnly is set.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
<execution>
<id>default-test</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
</executions>
</plugin>
So on the command line, I can disable install and test phases by adding -DdeployOnly.
mvn clean install #build and test everything
mvn deploy -DdeployOnly #just deploy it

I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.
Are you sure you understood correctly what you boss meant? I interpret the above as "don't install third party libraries in your local repository, use only libraries available in public repositories". This is different from "don't use your local repository" which is basically impossible, that's just not how maven works. I'd try to clarify this point.
Apart from that, I don't get the question which is very confusing (what repo are you talking about? What is the install script doing? Why do you call clean install on libraries? etc).

Extending the other answers, from the future.
Maven plugins have a surprisingly high freedom, how do they run. If they want, they can ignore/override the typical pom.xml settings. Furthermore, also the <configuration><skip>true</skip></configuration> is only a convention, nothing obligates a plugin to follow it, except that most of them is developed so.
My experiments with the recent problem show, that both #Cemo's and #MiloshBoroyevich solution should be utilized, also the plugin requires both to really let us in peace. More concretely, the only working configuration by me was this:
<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>
<configuration>
<skip>true</skip>
</configuration>
</plugin>

One of your options is to put the deployment to another module. I.e. have one pom.xml build the artifact and install it to the local repo, and another pom.xml to deploy it. This separation is quite common in larger projects, where the testsuite is sometimes a separate module or even a project, the packaging happens in several stages, etc.
- pom.xml - myProject-root - type=pom
- pom.xml - myProject-artifact - type=jar
- pom.xml - myProject-deploy - type=pom, does the deployment, skips it's own `install` goal

maven-release-plugin goals ignored in submodule in multi-module project

I have a multi-module Maven project. The project is laid out as follows
project/
pom.xml
types/
pom.xml
client/
pom.xml
service/
pom.xml
The types and client modules are built as JARs, service is built as a WAR. I'm using the maven-release-plugin to create new releases of this project. I would like to have the release plugin invoke extra goals when performing the release of the service module.
The release plugin is configured like so in the root pom (nothing special):
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
</plugin>
... and configured like so in the service pom along with the plugin I'm trying to invoke via the <goals> parameter:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<goals>deploy dockerfile:build dockerfile:push</goals>
</configuration>
</plugin>
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<configuration>
<repository>12345.ecr.us-east-1.amazonaws.com/project</repository>
</configuration>
</plugin>
The idea is that I'd like to build a Docker image for the service module but it doesn't make sense to build images for other modules in the project. However, when cutting a new release, the goals configuration in the service pom file are never invoked.
Maven version: 3.3.3
maven-release-plugin: 2.5.3
JDK: Oracle 1.8.0u144
The command being used:
mvn -Pstaging -B clean release:clean release:prepare release:perform
I'm not able to share the output from this command.
I've verified that the relevant configurations seem be be applied via
mvn -Pstaging help:effective-pom
My question is: Is what I'm trying to accomplish possible with the release plugin? I haven't found any questions or articles that indicate it's impossible.

With the caveat that I have never used the dockerfile-maven-plugin, try release profiles instead of goals.
Step 1. Edit the release plugin config in project/pom.xml.
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version> <!-- should define in pluginManagement -->
<configuration>
<releaseProfiles>publish-docker</releaseProfiles>
<!-- other plugin config -->
</configuration>
</plugin>
Choose a name for the profile that makes sense. I'll use publish-docker as the name here.
Step 2. Add a profile with that name to service/pom.xml:
<profiles>
<profile>
<id>publish-docker</id>
<build>
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<configuration>
<repository>12345.ecr.us-east-1.amazonaws.com/project</repository>
</configuration>
<executions>
<execution>
<id>docker-publish</id>
<phase>deploy</phase> <!-- important -->
<goals>
<goal>build</goal>
<goal>push</goal>
</goals>
</execution>
</executions>
</plugin>
</build>
</profile>
</profiles>
This profile includes plugin configuration that binds the dockerfile:build and dockerfile:push goals to the deploy phase. The release plugin will enable the publish-docker profile for each module. The profile will only exist in the service module, so that's where it will run.
One other thing I notice. In the release command:
mvn -Pstaging -B clean release:clean release:prepare release:perform
I suspect the -Pstaging part is not actually being applied during the release. The release plugin forks another process for each goal run. To pass the argument to the fork, the arguments parameter is required:
mvn -Pstaging -Darguments="-Pstaging" -B clean release:clean release:prepare release:perform

How to choose which JUnit5 Tags to execute with Maven

I have just upgraded my solution to use JUnit5. Now trying to create tags for my tests that have two tags: #Fast and #Slow. To start off I have used the below maven entry to configure which test to run with my default build. This means that when I execute mvn test only my fast tests will execute. I assume I can override this using the command line. But I can not figure out what I would enter to run my slow tests....
I assumed something like.... mvn test -Dmaven.IncludeTags=fast,slow which does not work
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<configuration>
<properties>
<includeTags>fast</includeTags>
<excludeTags>slow</excludeTags>
</properties>
</configuration>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.0.0-M3</version>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-surefire-provider</artifactId>
<version>1.0.0-M3</version>
</dependency>
</dependencies>
</plugin>

You can use this way:
<properties>
<tests>fast</tests>
</properties>
<profiles>
<profile>
<id>allTests</id>
<properties>
<tests>fast,slow</tests>
</properties>
</profile>
</profiles>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
<configuration>
<groups>${tests}</groups>
</configuration>
</plugin>
</plugins>
</build>
This way you can start with mvn -PallTests test all tests (or even with mvn -Dtests=fast,slow test).

Using a profile is a possibility but it is not mandatory as groups and excludedGroups are user properties defined in the maven surefire plugin to respectively include and exclude any JUnit 5 tags (and it also works with JUnit 4 and TestNG test filtering mechanism).
So to execute tests tagged with slow or fast you can run :
mvn test -Dgroups=fast,slow
If you want to define the excluded and/or included tags in a Maven profile you don't need to declare a new property to convey them and to make the association of them in the maven surefire plugin. Just use groups and or excludedGroups defined and expected by the maven surefire plugin :
<profiles>
<profile>
<id>allTests</id>
<properties>
<groups>fast,slow</groups>
</properties>
</profile>
</profiles>

You can omit profile and just use properties, it is more elastic way.
<properties>
<tests>fast</tests>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
<configuration>
<groups>${tests}</groups>
</configuration>
</plugin>
</plugins>
</build>
Then you can runt fast tests by typing mvn test, all test by typing mvn test -Dtests=fast | slow or only slow by typing mvn test -Dtests=slow. When you have more test tags then you can also run all of them except the selected type by typing mvn test -Dtests="! contract".

Choosing test category on command line

I am using JUnit's categories to split my tests into different categories and using maven to compile and run my test (surefire and failsafe).
Question is, how to I choose which category of tests are executed from command line?
something like: mvn clean install -DloadTests.
my failsafe plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>${failsafe.plugin.version}</version>
<configuration>
<!--Exclude load tests by default-->
<excludedGroups>com.test.lib.categories.LoadTestCategory</excludedGroups>
</configuration>
</plugin>

You could do that with profiles and specify the plugin configuration in there.
<profiles>
<profile>
<id>noLoadTests</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>${failsafe.plugin.version}</version>
<configuration>
<!--Exclude load tests by default-->
<excludedGroups>com.test.lib.categories.LoadTestCategory</excludedGroups>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
And then run maven
mvn test -PnoLoadTests
If you only ever need to exclude/include one specific category you could also define a property in the profile and use that in the . For more info you can look here
Edit: The other provided answer is the better one in this case, but profiles allow for various advanced configurations.

According to the documentation, user property is called groups. Therefore this should work:
mvn clean install -Dgroups=com.test.lib.categories.LoadTestCategory

Suppressing GPG signing for Maven-based continuous integration builds (Travis CI)

I'm using Travis-CI to provide continuous integration builds for a few Java open source projects I'm working on.
Normally this works smoothly, but I have a problem when the POM specifies GPG signing, e.g.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
This causes the Travis build to fail - apparently because it does not have a passphrase available while running mvn install. See this build for an example.
What is the best way to configure Maven and/or Travis to skip GPG signing for CI test builds, but still perform GPG signing when I do a proper release build?

Disable GPG signing by adding the following line to your .travis.yml file:
install: mvn install -DskipTests -Dgpg.skip
Example: https://github.com/stefanbirkner/system-rules/blob/master/.travis.yml

You need to create a profile & make sure you run that only when you do the release build.
Remove the current plugin, and add it in a profile like this:
<profiles>
<profile>
<id>release-sign-artifacts</id>
<activation>
<property>
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
And then when you actually need to do a release, add the property to your mvn command:
mvn -DperformRelease=true ...

I found a slightly simpler way to do it with the profile as described above. Instead of using a new property value, you can use the gpg.passphrase property which will need to be provided anyway when doing signing. The modified property section is as follows:
<activation>
<property>
<name>gpg.passphrase</name>
</property>
</activation>
Notice, that no value is required since you want this profile to activate if any value is set for that property.
The corresponding command line then looks like this:
mvn <command> -Dgpg.passphrase=myverysupersecretpassphrase
You can test this out by running it the following two ways:
mvn install
No signed artifacts get generated, and:
mvn install -Dgpg.passphrase=myverysupersecretpassphrase
Signed artifacts get created.
To do the actual signed release of the artifacts do the following:
mvn release:perform -Darguments=-Dgpg.passphrase=myverysupersecretpassphrase
The indirection is needed for the release action because it doesn't propagate the command line arguments directly to the spawned process (see http://maven.apache.org/plugins/maven-gpg-plugin/usage.html).