Maven Install Plugin
  1. Maven Install Plugin
  2. MINSTALL-30

Command Line parameter 'version' does not override pom file

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • 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

          Activity

          Hide
          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>
          Jason Dillon made changes -
          Field Original Value New Value
          Link This issue relates to MINSTALL-37 [ MINSTALL-37 ]
          Carlos Sanchez made changes -
          Fix Version/s 2.2 [ 12256 ]
          Fix Version/s 2.3 [ 13495 ]
          Hide
          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.
          Wendy Smoak made changes -
          Fix Version/s 2.3 [ 13495 ]
          Hide
          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.
          Dennis Lundberg made changes -
          Issue Type Bug [ 1 ] New Feature [ 2 ]
          Hide
          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.
          Dennis Lundberg made changes -
          Component/s install:install [ 13801 ]
          Hide
          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.
          Hide
          Robert Scholte added a comment -

          Most artifacts have a META-INF/maven/${groupId}/${artifactId}/pom.xml which would mean these versions are out of sync.
          So the install phase is too late to fix the version.

          The issue of Dan Tran seems to be with install-file rather than install.

          For continuous integration you shouldn't abuse the pom.xml, the file which contains the build-instructions. If you want to uniquely identify the build-result you can add a revision-number to the MANIFEST-file (see buildnumber-maven-plugin) or add your custom file to the artifact.

          The main purpose of the local repository is to have a folder structure so other projects can refer to these artifacts by specifying a dependency, plugin, etc. IMHO for that same reason it is wrong to use this local repository as the location for distributable/deployables/end-products, since you'll never refer to these files.

          I'm pretty sure there are better solutions then specifying a version during the install.
          I noticed there are quite a lot of votes and watchers for this issue. I'd be glad to help those with a better more solid solution.

          Show
          Robert Scholte added a comment - Most artifacts have a META-INF/maven/${groupId}/${artifactId}/pom.xml which would mean these versions are out of sync. So the install phase is too late to fix the version. The issue of Dan Tran seems to be with install-file rather than install . For continuous integration you shouldn't abuse the pom.xml , the file which contains the build- instructions . If you want to uniquely identify the build- result you can add a revision-number to the MANIFEST-file (see buildnumber-maven-plugin ) or add your custom file to the artifact. The main purpose of the local repository is to have a folder structure so other projects can refer to these artifacts by specifying a dependency, plugin, etc. IMHO for that same reason it is wrong to use this local repository as the location for distributable/deployables/end-products, since you'll never refer to these files. I'm pretty sure there are better solutions then specifying a version during the install. I noticed there are quite a lot of votes and watchers for this issue. I'd be glad to help those with a better more solid solution.
          Robert Scholte made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Assignee Robert Scholte [ rfscholte ]
          Resolution Won't Fix [ 2 ]

            People

            • Assignee:
              Robert Scholte
              Reporter:
              Johan Fischer
            • Votes:
              5 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: