3

I have a project which I am attempting to install with maven. The pom.xml has a few properties in it which are modified when the maven install command is run depending on whatever version of a library we are attempting to build with:

<properties>
  <some-version>0</some-version>
</properties>

The zero here is a placeholder, as we'll always specify a legitimate version during our build process. The version is then referenced later in the pom.xml to specify a few dependencies:

  <dependencies>
    <dependency>
      <groupId>com.mycompany.myproduct</groupId>
      <artifactId>someOtherProject</artifactId>
      <version>${some-version}</version>
    </dependency>
  </dependencies

Building is done via make with the following commandline:

mvn -Dsome-version=1.6.2

Maven is able to correctly resolve the version and build as expected. However, the version being installed in my local maven repository (/home/user/.m2) doesn't have the correct version. The pom.xml that is installed does not have the updated version I set in the command line:

user@ubuntu:~/$ cat /home/user/.m2/repository/com/mycompany/myproduct/myproject/1.0.0/myproject-1.0.0.pom | grep some-version -C 1

  <properties>
    <some-version>0</some-version>
  </properties>
--
      <artifactId>someOtherProject</artifactId>
      <version>${some-version}</version>
    </dependency>
user@ubuntu:~/$

This is preventing any other project which depends on myproject from being able to build, as maven will complain that it can't find version 0 of someOtherProject:

[ERROR] Failed to execute goal on project myproject: 
Could not resolve dependencies for project mycompany.myproduct:myproject:jar:1.0.0: 
The following artifacts could not be resolved: com.mycompany.myproduct:someOtherProject:jar:0, 
Could not find artifact com.mycompany.myproduct:someOtherProject:jar:0 in central (https://mycompany.com/artifactory/repo/) -> [Help 1]

What do I need to do for maven to install with the updated version in the pom? Obviously a terrible hackish solution would be to use sed and modify the pom file directly, but it seems that Maven should be able to actually leverage the command line settings when installing the pom. Otherwise the ability to set arguments on the command line seems remarkably limited in effectiveness.

Razib
  • 10,965
  • 11
  • 53
  • 80
user2093082
  • 407
  • 8
  • 19
  • Better use the [versions](http://mojo.codehaus.org/versions-maven-plugin/) plugin with its commands. – Joop Eggen May 08 '15 at 14:31
  • We already do use the versions plugin, but as far as I know that only set's the version for the project itself. It does not solve the issue of setting properties. – user2093082 May 08 '15 at 14:35
  • Yes it works the other way around. I assume you have a multi-module projects with a parent hierarchy. Sorry if the examples on the page offered no solution. There also is central ****. – Joop Eggen May 08 '15 at 14:47
  • First it sounds strange that you dynamically change the version of a dependency cause if you do a build with a particular version this shows the user that your project uses this dependency in that version (transitve dependency). The question is why you need to change it if you call an install? If the version of your library changes why not changing the pom and checking in the change. You might think about defining the dependency as a scope:runtime or maybe you need to define the dependency as optional? – khmarbaise May 08 '15 at 14:54
  • @JoopEggen, I looked deeper into the versions plugin. It has an option which **looks** like it does exactly what I need - [update-property](http://mojo.codehaus.org/versions-maven-plugin/update-property-mojo.html), but the expected behavior isn't there: – user2093082 May 08 '15 at 16:35
  • (continued) `mvn versions:update-property -Dproperty=some-version -DnewVersion=1.6.2 -X [DEBUG] Property ${some-version}: Set of valid available versions is [] [DEBUG] Property ${some-version}: Restricting results to 1.6.2 [DEBUG] Property ${some-version}: Current winner is: null [DEBUG] Property ${some-version}: Searching reactor for a valid version... [DEBUG] Property ${some-version}: Set of valid available versions from the reactor is [] [INFO] Property ${some-version}: Leaving unchanged as 0` – user2093082 May 08 '15 at 16:35
  • Ah. Adding -DsearchReactor=false seemed to fix it, even though it's not a listed option. @Joop if you want to write an answer, I'll accept it. If not I'll write one myself detailing the plugin once I am allowed to write my own answer. – user2093082 May 08 '15 at 17:20

3 Answers3

1

Better you may set your property in pom.xml in <properties> tag like this - 

<properties>
    <property>
        <name>some-version</name>
        <value>1.6.2</value>
    </property>
</properties>

If you use this then you don't have to provide the property each time you issue a mvn command from terminal.

Razib
  • 10,965
  • 11
  • 53
  • 80
  • 2
    We're setting it in the command line because the version isn't constant. Hardcoding obviously solves the problem listed but doesn't work for the use case in the first place - hence why we're setting it via the command line. – user2093082 May 08 '15 at 14:26
1

mvn -Dsome-version=1.6.2 works as a substitution value for the scope of building than replacing the original POM with the new values. Hence is the behavior you see. I am not aware of any maven support to do so.

jags
  • 176
  • 5
1

Under @JoopEggen's advice, I looked deeper into the maven versions plugin. It offered an update-property target which will actually update the pom.xml value on disk, rather than just passing in an overwrite during the build phase. I was able to solve my issue by calling

mvn versions:update-property -Dproperty=some-version -DnewVersion=1.6.2 -DsearchReactor=false -DallowSnapshots=true

in the makefile before calling mvn install. Disabling the reactor was necessary to prevent the plugin from rejecting values it couldn't find in the remote repo (see here), and allowSnapshots allows me to use version numbers such as 1.6.2-SNAPSHOT, useful when testing.

user2093082
  • 407
  • 8
  • 19