maven-deploy-plugin Ignores Version Number?

Question

I am new to Maven, and I am try to deploy my project as a war, and as a jar. I would love to split the project to do the same, but it is too large for simple me to do in a reasonable time.

I found maven deploy additional jar file , which suggested I add some plugins.

The install plugin works great

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-install-plugin</artifactId>
    <executions>
        <execution>
            <phase>install</phase>
            <goals>
                <goal>install-file</goal>
            </goals>
            <configuration>
                <packaging>jar</packaging>
                <artifactId>${project.artifactId}</artifactId>
                <groupId>${project.groupId}</groupId>
                <version>SNAPSHOT</version>
                <file>
                    ${project.build.directory}/${project.artifactId}-SNAPSHOT.jar
                </file>
            </configuration>
        </execution>
    </executions>
</plugin>

Here is the output:

[INFO] [install:install-file {execution: default}]
[INFO] Installing C:\Server\example\code\server\my-project\target\my-project-SNAPSHOT.jar to C:\Users\Kyle\.m2\repository\com\example\main-project\my-project\SNAPSHOT\my-project-SNAPSHOT.jar

The problem is with the maven-deploy-plugin. It seems to ignore the SNAPSHOT version I am forcing it to use:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-deploy-plugin</artifactId>
    <executions>
        <execution>
            <phase>deploy</phase>
            <goals>
                <goal>deploy-file</goal>
            </goals>
            <configuration>
                <packaging>jar</packaging>
                <generatePom>true</generatePom>
                <url>${project.distributionManagement.snapshotRepository.url}</url>
                <artifactId>${project.artifactId}</artifactId>
                <groupId>${project.groupId}</groupId>
                <version>SNAPSHOT</version>
                <!--${project.version}!="SNAPSHOT" for some reason-->
                <file>${project.build.directory}/${project.artifactId}-SNAPSHOT.jar</file>
            </configuration>
        </execution>
    </executions>
</plugin>

Seems to use some other version number (YYYYMMDD.HHmmSS-#)

[INFO] [deploy:deploy-file {execution: default}]
[INFO] Retrieving previous build number from remote-repository
Uploading: http://build.example.biz:8081/artifactory/libs-snapshots-local/com/example/main-project/my-project/SNAPSHOT/my-project-20120625.161551-2.jar
42993K uploaded  (my-project-20120625.161551-2.jar)

What am I doing wrong?

Answer 1

One thing i observed is that you are using the version SNAPSHOT without any kind of preceding numbers like:

1.0.0-SNAPSHOT

or at least:

1-SNAPSHOT

You are just using SNAPSHOT this does not make sense, cause of which development line you are talking in this case.

The other thing is that a SNAPSHOT (assuming you are using it in the right way) in Maven is an artifact where a timestamp will be put instead of the SNAPSHOT. That's the way to make it possible having multiple SNAPSHOT being released but make them distinguishable.

So the thing you've showed in your output is exactly what Maven makes out of the SNAPSHOT:

[INFO] [deploy:deploy-file {execution: default}]
[INFO] Retrieving previous build number from remote-repository
Uploading: http://build.example.biz:8081/artifactory/libs-snapshots-local/com/example/main-project/my-project/SNAPSHOT/my-project-20120625.161551-2.jar
42993K uploaded  (my-project-20120625.161551-2.jar)

Answer 2

In the respective remote repository there is a http://build.example.biz:8081/artifactory/libs-snapshots-local/com/example/main-project/my-project/SNAPSHOT/maven-metadata.xml . If you have a look at it, you will see that the latest timestamp is mapped to your respective SNAPSHOT . This is typical behavior under both Maven 2 and 3. I believe it's the default behavior under Maven 3 to use timestamped SNAPSHOT -s.

When you try downloading the artifact via Maven, I believe it will resolve it correctly for you, so you shouldn't really be alarmed.