Maven 2.x Install Plugin

Command Line parameter 'version' does not override pom file

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.1
  • Fix Version/s: None
  • Component/s: install:install
  • Labels:
    None
  • Environment:
    maven 2.0.4
    maven-install-plugin 2.1
  • Number of attachments :
    0

Description

Hi,

I'm trying to override the version number in the pom using the CLI params -Dversion but the install plugin still uses the pom version creating a mismatched of the installed jar file:

example:
pom version: SHIP_VERSION 

$ mvn -X -Dversion=1.4.1_2 install
 Error stacktraces are turned on.
Maven version: 2.0.4
[DEBUG] Building Maven user-level plugin registry from: '/home/jfischer/.m2/plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from: '/opt/maven/conf/plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM: cmss:parent::1.0.0-SNAPSHOT of project: cmss-libs:cmcrc-favlib:jar:SHIP_VERSION in relative path: ../pom.xml
[DEBUG] Parent-POM: cmss:parent::1.0.0-SNAPSHOT not found in relative path: ../pom.xml
[DEBUG] Retrieving parent-POM: cmss:parent::1.0.0-SNAPSHOT for project: cmss-libs:cmcrc-favlib:jar:SHIP_VERSION from the repository.
[DEBUG] Skipping disabled repository central
[DEBUG] parent: resolved to version 1.0.0-20060516.064917-2 from repository cmss
[INFO] ----------------------------------------------------------------------------
[INFO] Building Java SMARTS lib
[INFO]    task-segment: [install]
[INFO] ----------------------------------------------------------------------------

<--- snip --->

DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.0.1:compile' -->
[DEBUG]   (f) basedir = /home/jfischer/cmcrc/cmss/libs/favlib
[DEBUG]   (f) buildDirectory = /home/jfischer/cmcrc/cmss/libs/favlib/target
[DEBUG]   (f) classpathElements = [/home/jfischer/cmcrc/cmss/libs/favlib/target/classes, /home/jfischer/.m2/repository/cmss-libs/jelte-util/1.0.0/jelte-util-1.0.0.j
ar]
[DEBUG]   (f) compileSourceRoots = [/home/jfischer/cmcrc/cmss/libs/favlib/src/main/java]
[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true
[DEBUG]   (f) fork = false
[DEBUG]   (f) optimize = false
[DEBUG]   (f) outputDirectory = /home/jfischer/cmcrc/cmss/libs/favlib/target/classes
[DEBUG]   (f) outputFileName = cmcrc-favlib-1.4.1_2
[DEBUG]   (f) projectArtifact = cmss-libs:cmcrc-favlib:jar:SHIP_VERSION
[DEBUG]   (f) showDeprecation = false
[DEBUG]   (f) showWarnings = false
[DEBUG]   (f) staleMillis = 0
[DEBUG]   (f) verbose = false
[DEBUG] -- end configuration --

<--- snip --->

[DEBUG] org.apache.maven.plugins:maven-install-plugin:maven-plugin:2.1:runtime (selected for runtime)
[DEBUG]   org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for runtime)
[DEBUG]   org.apache.maven:maven-project:jar:2.0:runtime (selected for runtime)
[DEBUG]     org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime (selected for runtime)
[DEBUG]       junit:junit:jar:3.8.1:runtime (selected for runtime)
[DEBUG]       org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for runtime)
[DEBUG]       classworlds:classworlds:jar:1.1-alpha-2:runtime (selected for runtime)
[DEBUG]     org.apache.maven:maven-profile:jar:2.0:runtime (selected for runtime)
[DEBUG]       org.apache.maven:maven-model:jar:2.0:runtime (selected for runtime)
[DEBUG]     org.apache.maven:maven-model:jar:2.0:runtime (selected for runtime)
[DEBUG]     org.apache.maven:maven-artifact-manager:jar:2.0:runtime (selected for runtime)
[DEBUG]       org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime)
[DEBUG]       org.apache.maven:maven-artifact:jar:2.0:runtime (selected for runtime)
[DEBUG]       org.apache.maven:maven-repository-metadata:jar:2.0:runtime (selected for runtime)
[DEBUG]     org.apache.maven:maven-artifact:jar:2.0:runtime (selected for runtime)
[DEBUG]     org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for runtime)
[DEBUG]   org.apache.maven:maven-artifact:jar:2.0:runtime (selected for runtime)
[DEBUG]   org.apache.maven:maven-artifact-manager:jar:2.0:runtime (selected for runtime)
[DEBUG]     org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime)
[DEBUG]     org.apache.maven:maven-repository-metadata:jar:2.0:runtime (selected for runtime)
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-install-plugin:2.1:install' -->
[DEBUG]   (f) artifact = cmss-libs:cmcrc-favlib:jar:SHIP_VERSION
[DEBUG]   (f) attachedArtifacts = []
[DEBUG]   (f) localRepository = [local] -> file:///home/jfischer/.m2/repository
[DEBUG]   (f) packaging = jar
[DEBUG]   (f) pomFile = /home/jfischer/cmcrc/cmss/libs/favlib/pom.xml
[DEBUG] -- end configuration --
[INFO] [install:install]
[INFO] Installing /home/jfischer/cmcrc/cmss/libs/favlib/target/cmcrc-favlib-1.4.1_2.jar to /home/jfischer/.m2/repository/cmss-libs/cmcrc-favlib/SHIP_VERSION/cmcrc-f
avlib-SHIP_VERSION.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10 seconds
[INFO] Finished at: Wed Aug 02 12:36:09 GMT+10:00 2006
[INFO] Final Memory: 4M/9M
[INFO] ------------------------------------------------------------------------

As you can see, the install plugin installed the built jar file 1.4.2_2 to the local repos version=SHIP_VERSION......
Looking at the trunk code: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java

this makes perfect sense as if the pom file exists, it reads the version from there and skip CLI parsing as requested in MINSTALL-21. So would be nice to read first the pom, and then allow the CLI to override this. I don't know if you want to allow overriding the groupId and artifactId (I just looked at the version case).

Cheers.

Issue Links

relates to

New Feature - A new feature of the product, which has yet to be developed. MINSTALL-37 Add support to force install:install to use a specific version

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dan Tran added a comment -

I have a use case that need to have overridable groupid and artifactid, etc

I would like to use a pom file to deploy/install a bunch of thirdparty jars into my internal remote repo. The pom execute install:install-file mutliple times.
The advantage of the approach is it not OS dependent.

The below pom throws this errror

[INFO] Error configuring: org.apache.maven.plugins:maven-install-plugin. Reason:
ERROR: Cannot override read-only parameter: artifactId in goal: install:install-file

here is the pom

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>net.java.jaxws.ri</groupId>
<artifactId>jaxws-ri-deployer</artifactId>
<version>1.0-SNAPSHOT</version>

<packaging>pom</packaging>

<name>jaxws-ri deployer</name>

<build>

<defaultGoal>package</defaultGoal>

<plugins>
<plugin>
<artifactId>maven-install-plugin</artifactId>
<configuration>
<groupId>net.java.jaxws.ri</groupId>
<version>$

{jaxws.ri.version}

</version>
<generatePom>true</generatePom>
<packaging>jar</packaging>
</configuration>
<executions>
<execution>
<id>http.jar</id>
<goals>
<goal>install-file</goal>
</goals>
<phase>package</phase>
<configuration>
<artifactId>http</artifactId>
<file>httpd.jar</file>
</configuration>
</execution>
<execution>
<id>resolver.jar</id>
<goals>
<goal>install-file</goal>
</goals>
<phase>package</phase>
<configuration>
<artifactId>resolver</artifactId>
<file>resolver.jar</file>
</configuration>
</execution>
.......

</executions>
</plugin>
</plugins>
</build>

<properties>
<jaxws.ri.version>2.1-EA3</jaxws.ri.version>
</properties>

</project>

Show
Dan Tran added a comment - I have a use case that need to have overridable groupid and artifactid, etc I would like to use a pom file to deploy/install a bunch of thirdparty jars into my internal remote repo. The pom execute install:install-file mutliple times. The advantage of the approach is it not OS dependent. The below pom throws this errror [INFO] Error configuring: org.apache.maven.plugins:maven-install-plugin. Reason: ERROR: Cannot override read-only parameter: artifactId in goal: install:install-file here is the pom <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd "> <modelVersion>4.0.0</modelVersion> <groupId>net.java.jaxws.ri</groupId> <artifactId>jaxws-ri-deployer</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <name>jaxws-ri deployer</name> <build> <defaultGoal>package</defaultGoal> <plugins> <plugin> <artifactId>maven-install-plugin</artifactId> <configuration> <groupId>net.java.jaxws.ri</groupId> <version>$ {jaxws.ri.version} </version> <generatePom>true</generatePom> <packaging>jar</packaging> </configuration> <executions> <execution> <id>http.jar</id> <goals> <goal>install-file</goal> </goals> <phase>package</phase> <configuration> <artifactId>http</artifactId> <file>httpd.jar</file> </configuration> </execution> <execution> <id>resolver.jar</id> <goals> <goal>install-file</goal> </goals> <phase>package</phase> <configuration> <artifactId>resolver</artifactId> <file>resolver.jar</file> </configuration> </execution> ....... </executions> </plugin> </plugins> </build> <properties> <jaxws.ri.version>2.1-EA3</jaxws.ri.version> </properties> </project>
Hide
Permalink
Wendy Smoak added a comment -

This has been scheduled since early 2007, with no activity. Moving it to unscheduled.

Show
Wendy Smoak added a comment - This has been scheduled since early 2007, with no activity. Moving it to unscheduled.
Hide
Permalink
Dennis Lundberg added a comment -

Changing this from "Bug" to "New Feature" since the install:install mojo doesn't currently have a version parameter.

Show
Dennis Lundberg added a comment - Changing this from "Bug" to "New Feature" since the install:install mojo doesn't currently have a version parameter.
Hide
Permalink
Matthew Jaskula added a comment -

Here is a simple workaround to allow version numbers from the command line to override the version used by the install and deploy plugins. In our case the continuous integration server is providing the version number, which includes a build number. I didn't test group or artifact ids, but this same scheme may work for them as well.

By using a level of indirection you can pass a version number in to the pom at build time and have the install and deploy plugins use them. For example:

<project xmlns="..." xmlns:xsi="..." xsi:schemaLocation="...">
<modelVersion>4.0.0</modelVersion>
<groupId>org.codehaus</groupId>
<artifactId>codehaus</artifactId>
<version>$

{ciVersion}

</version>
<packaging>jar</packaging>

<properties>
<ciVersion>0.0.0.0</ciVersion>
</properties>

...

</project>

We cannot override $

{project.version} directly. So instead, we add a second property called 'ciVersion' and give it a default value of '0.0.0.0' in the properties section. Now the CI server can specify a version number by overriding the ciVersion property on the command line. As in:

mvn -DciVersion=1.0.0.25 install

The install and deploy plugins will use the value of the ciVersion property that was passed in whenever ${project.version}

is referenced, as expected, and the default value will be used when no version is provided on the command line.

Show
Matthew Jaskula added a comment - Here is a simple workaround to allow version numbers from the command line to override the version used by the install and deploy plugins. In our case the continuous integration server is providing the version number, which includes a build number. I didn't test group or artifact ids, but this same scheme may work for them as well. By using a level of indirection you can pass a version number in to the pom at build time and have the install and deploy plugins use them. For example: <project xmlns="..." xmlns:xsi="..." xsi:schemaLocation="..."> <modelVersion>4.0.0</modelVersion> <groupId>org.codehaus</groupId> <artifactId>codehaus</artifactId> <version>$ {ciVersion} </version> <packaging>jar</packaging> <properties> <ciVersion>0.0.0.0</ciVersion> </properties> ... </project> We cannot override $ {project.version} directly. So instead, we add a second property called 'ciVersion' and give it a default value of '0.0.0.0' in the properties section. Now the CI server can specify a version number by overriding the ciVersion property on the command line. As in: mvn -DciVersion=1.0.0.25 install The install and deploy plugins will use the value of the ciVersion property that was passed in whenever ${project.version} is referenced, as expected, and the default value will be used when no version is provided on the command line.
Hide
Permalink
Joern Gebhardt added a comment -

@Matthew

The install and deploy plugins will use the value of the ciVersion property that was passed in whenever ${project.version} is referenced, as expected...

Your are right in the sense, that the artifact will end up at the correct location in the repository, i.e. the ciVersion is reflected in the path and the artifact name. However, additionally to the main artifact also the pom.xml gets uploaded into the repository (e.g. my-artiact-1.0.0.25.pom). If you look inside this POM you will see that the original source POM was uploaded that contains as version the ciVersion property. I.e. Maven will have problems resolving the correct transitive dependencies if you are in a multi-module project as it will look for a parent with the unresolved version "$

{ciVersion}

". Instead of uploading the unresolved source pom.xml Maven should upload the resolved one.

Show
Joern Gebhardt added a comment - @Matthew The install and deploy plugins will use the value of the ciVersion property that was passed in whenever ${project.version} is referenced, as expected... Your are right in the sense, that the artifact will end up at the correct location in the repository, i.e. the ciVersion is reflected in the path and the artifact name. However, additionally to the main artifact also the pom.xml gets uploaded into the repository (e.g. my-artiact-1.0.0.25.pom ). If you look inside this POM you will see that the original source POM was uploaded that contains as version the ciVersion property. I.e. Maven will have problems resolving the correct transitive dependencies if you are in a multi-module project as it will look for a parent with the unresolved version "$ {ciVersion} ". Instead of uploading the unresolved source pom.xml Maven should upload the resolved one.

People

  • Assignee:
    Unassigned
    Reporter:
    Johan Fischer
Vote (5)
Watch (8)

Dates

  • Created:
    Updated: