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 generate separate jar files for application, source, and documentation (for central.sonatype.org)

Sonatype has a repository that I want to deploy a jar file to, and they ask for separate files for application, sources, and javadocs:
Example:
example-application-1.4.7.pom
example-application-1.4.7.jar
example-application-1.4.7-sources.jar
example-application-1.4.7-javadoc.jar
In Scala SBT, I have a command called "package" that generates the jar file for the project, but that only generates "example-application-1.4.7.jar".
Question: What should I do to generate the other two jar files?

In Maven, in order to get the additional -sources and -javadoc artifacts, add to your POM file the following:
<build>
<plugins>
<!-- additional plugin configurations, if any.. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.3</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note the snippet above:
We are invoking the Maven Source Plugin to create an additional jar files for sources
We are invoking the Maven Javadoc Plugin to create an additional jar files for javadoc
Executing
mvn clean package
You will find these two additional jars in the target folder.
The .pom file instead is generated during the install phase, but it is not placed under the target folder. Basically, it is a copy of your pom.xml file, with a different extension and used by Maven during the dependency mediation process to check which transitive dependencies are required by the concerned artifact.
Executing
mvn clean install
Maven will install the artifact in your local cache (in your machine), under path_to_cache/.m2/repository/your_groupId/your_artifactId/your_version/. In this folder, you will also find the .pom file, which normally you don't need to distribute (it is created automatically by Maven).
Further note: you probably don't want to generate these additional jar files at each and every build, so to speed up normal builds and have them only on demand, you could wrap the snippet above in a Maven profile.
You can achieve this by removing the snippet above from your build section and add a further section at the end of your pom:
<profiles>
<profile>
<id>prepare-distribution</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.3</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
So that normal builds would not create these jars anymore, but when executing the following:
mvn clean install -Pprepare-distribution
You would instead get them back. the -P option is actually activating on demand the profile defined with the id prepare-distribution.
With Maven 3 a default profile already comes as part of the super pom which perform exactly the same actions (sources and javadoc artifact), hence no need to add anything to your existing project. Simply run:
mvn clean install -Prelease-profile
Or, to activate it via a property
mvn clean install -DperformRelease=true
However, as also specified in the super pom, this profile may be removed in future releases (although there since first Maven 3 version till version 3.3.9 so far)
NOTE: The release profile will be removed from future versions of the super POM
The main reason behind this warning is most probably to push for the usage of the Maven Release Plugin, which indirectly makes use of this profile via the useReleaseProfile option of the release:perform goal.
As highlighted by comments, if you are not familiar with maven (especially via console) I would definitely recommend to
Go through the official Maven in 5 minutes documentation for a quick but worthy look.
Play with Maven from the command line, is there where Maven gives you its best. IDE integrations are great, but command line is the real turning point.
Then play with the POM customization above, to get familiar with some concepts and behaviors, first directly as part of your default build, then moved to a profile.
Then, and only then, move to the Maven Release Plugin usage. I recommend it as last step because you would already have acquired more confidence and understanding and see it as less magic and more reasonable approach.

Maven: how to do runable jar (uberjar) with included external libraries

Until now i made runnable jars with Ant and there were no problems with it.
However i now try to mavenize my project and i realy can't figured out how to do runable jar with this tool.
I've read tons of tutorials (also here, on Stackoverflow), helps, advices and... nothing. In my case all of them don't work which probably means i don't understand some basics.
I have such simple project:
This is app, witch use mysql-connector-java-5.1.24-bin.jar (placed in 'lib' dir) to connect to MySQL database.
I want to include this jar into final jar (DBPreformatter.jar).
I used assembly and shaded plugins in many configurations, but they NEVER added this jar into DBPreformatter.jar.
This is my pom.xml:
<modelVersion>4.0.0</modelVersion>
<groupId>com.icd4you</groupId>
<artifactId>DBPreformatter</artifactId>
<version>1.0.0</version>
<name>DBPreformatter</name>
<description>DB processing and cleaning tool</description>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>mysql-connector-java-5.1.24-bin</groupId>
<artifactId>mysql-connector-java-5.1.24-bin</artifactId>
<version>5.1.24</version>
<scope>system</scope>
<systemPath>${basedir}/lib/mysql-connector-java-5.1.24-bin.jar</systemPath>
</dependency>
</dependencies>
<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>
<!-- WHAT SHOULD I USE HERE? -->
</plugins>
</build>
How to solve this problem?

There is a maven plugin Apache Maven Shade Plugin that will build an uber jar for you

Add the Maven Assembly plugin with the descriptor jar-with-dependencies:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>com.pany.your.MainClass</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
Note that this doesn't add the JAR; instead it unpacks all JARs which are listed as dependencies and adds their content to the resulting JAR (so you'll see all the class files from the MySQL JAR in the result instead of the MySQL JAR itself).
EDIT There is a caveat, though: Maven ignores JARs with scope=system for many operations. See also: How to include external jars in maven jar build process?
If Maven doesn't add the JAR to the output, then you must install all JARs with this scope into your local maven repo ($HOME/.m2/repository) using the mvn install:file-install command. See http://maven.apache.org/plugins/maven-install-plugin/usage.html how to do that.
Note: Installing libraries in your local repo is the preferred way; you should really consider it. For one, the scope=system will no longer confuse you (since many plugins handle them in a special way). Plus you need to do this only once. Afterwards, you can use this library in many Maven projects.
Before installing, you should check http://search.maven.org/ to see if the dependency isn't already known to Maven.
MySQL is: http://search.maven.org/#artifactdetails%7Cmysql%7Cmysql-connector-java%7C5.1.32%7Cjar

Maven: how to copy artifact to specific directory?

The "install" goal copies the artifact to the target directory and to the local repository.
How can I tell Maven to copy it also to a given directory (like the deploy directory of JBoss for example).

The goal copy of maven-dependency-plugin does what you want, see the example.
It is however not a good idea to copy anything outside your target directory (or ${project.build.directory} to be precise) - especially if such action is attached to a build phase, because it introduces unexpected side-effects of the build, and sometimes even loss of reproducibility.
As #Andreas_D notes, there is a better alternative for JBoss deployment purpose; similarly for deploying to other appservers.

According to http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html you can copy the just built artifact to a specific directory:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>copy-installed</id>
<phase>install</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<type>${project.packaging}</type>
</artifactItem>
</artifactItems>
<outputDirectory>some-other-place</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>

If you want to copy file to a webserver (local or distant) you can use Maven upload plugin :
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-upload-plugin</artifactId>
<version>1.1</version>
<configuration>
<resourceSrc>
${project.build.directory}/${project.build.finalName}.${project.packaging}
</resourceSrc>
<resourceDest>${jboss.deployDir}</resourceDest>
<serverId>${jboss.host}</serverId>
<url>${jboss.deployUrl}</url>
</configuration>
</plugin>
And to configure parameters in a smart way, I use maven profiles :
<profiles>
<!-- local deployment -->
<profile>
<id>developpement</id>
<properties>
<jboss.host>localhost</jboss.host>
<jboss.deployDir>appli/jboss-4.0.4.GA/server/default/deploy/</jboss.deployDir>
<jboss.deployUrl>file://C:/</jboss.deployUrl>
</properties>
</profile>
<!-- distant deployment -->
<profile>
<id>validation</id>
<properties>
<jboss.host>ENV_val</jboss.host>
<jboss.deployDir>/home/envval/jboss/server/default/deploy/</jboss.deployDir>
<jboss.deployUrl>scp://PROJECT_LAN_HOST</jboss.deployUrl>
</properties>
</profile>
</profiles>
I've created an "ant launcher", to use it by clicking under Eclipse ant view :
<target name="copy war to JBoss local" description="Copy war to local JBoss">
<maven goal="upload:upload" options="-Pdeveloppement" />
</target>
But you can simply run it on a command line :
mvn upload:upload -Pdeveloppement
By the way, for distant deployment, you may need a login password for scp to work. You have to add them to you Maven settings.xml file :
<settings>
...
<servers>
<server>
<id>ENV_val</id>
<username>login</username>
<password>password</password>
</server>
</servers>
...
</settings>

The best approach would be to use a plugin which will actually deploy your application, such as cargo or jboss-maven plugin (credit to #Andreas_D for that one).
This would be a better approach to using a copy or generic upload tool since deploying is what you are actually trying to do.
With the cargo plugin you have the option to deploy to a variety of running servers. We took this approach to test locally in jetty using the jetty plugin during the build and had a profile to deploy to tomcat on demand via cargo.
Note: If you have your target server (JBOSS) installed locally on the dev box as well then you can also use cargo to start/stop your server during your build process as well. The downside of this approach is that you will need it to reference it's location in the pom file, so either all devs install it in the same location or a system property that defines where it is located (similar to JAVA_HOME).