Maven copy artifact to different directory than the local repository

The maven-jar-plugin creates the artifacts jar into ${project.build.directory} (by default target/). The maven-install-plugin copies this file to the local Maven repository (by default %user.home%/.m2/repository).

Sometimes it is wanted to additionally copy this artifact into another location. For example to deploy the artifact to a server. Two possibilities come to my mind to solve this problem:

maven-antrun-plugin and Ant's copy task
copy-maven-plugin by Evgeny Goldin

For example, one could copy all *.jar files in the target directory like this:

<plugin>
  <groupId>com.github.goldin</groupId>
  <artifactId>copy-maven-plugin</artifactId>
  <version>0.2.5</version>
  <executions>
    <execution>
      <id>deploy-to-local-directory</id>
      <phase>install</phase>
      <goals>
        <goal>copy</goal>
      </goals>
      <configuration>
        <skipIdentical>false</skipIdentical>
        <failIfNotFound>false</failIfNotFound>
        <resources>
          <resource>
            <description>Copy artifact to another directory</description>
            <targetPath>your/local/path</targetPath>
            <directory>${project.build.directory}</directory>
            <includes>
              <include>*.jar</include>
            </includes>
          </resource>
        </resources>
      </configuration>
    </execution>
  </executions>
</plugin>

Suggested from me at stackoverflow.

Test-driven Configuration Management with Maven

As an agile software developer practicing test-driven development (TDD) it is normal to write the tests first. Unfortunately, switching roles and wearing the "configuration manager hat" it is sometimes hard to adhere to the same rules of TDD because there are tools missing which provides test infrastructure for build management. One solution might be to use the build server for such tasks.

This is an example of Test-driven dependency mangement with Maven:

We can use the versions-maven-plugin to list all available updates of plugins used in the pom.xml.

For example Maven might produce this information on an updated version of the release plugin:

mvn versions:display-property-updates
...
[08:01:04][de.timomeinen.maven:maven-parent] 
[INFO] The following version property updates are available:
[08:01:04][de.timomeinen.maven:maven-parent] 
[INFO] ${version.plugin.release}......... 2.4.1 -> 2.4.2

If we trigger a nightly build on the CI server and let the build fail on an update message, we have a nice test if there are any updates available for our Maven project.

This example uses TeamCity, but you can surely adopt it to other CI server as well.

Configure a new Maven Build Step:

And define a Build Failure Condition (Step 4):

Fail build if build log contains exact text "The following version property updates are available" with the Failure message "Updates available".

The result looks like this:

This will let the build fail on a dependency update, gives you a nice message and TeamCity even produces a link to the part of the build log, where you can see which dependencies you can update.

That's a nice example of what I call "Test-driven System Administration (TDSA)".

List all properties used by Maven

List all properties (System properties, environment variables, properties introduced by plugins like ) used by Maven:

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.7</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <configuration>
                <target>
                    <echoproperties />
                </target>
            </configuration>
            <goals>
                <goal>run</goal>
            </goals>
        </execution>
    </executions>
</plugin>