37

I have two top-level Maven projects, backend and frontend, that advance versions at their own individual pace. Since each has multiple modules, I define my dependency versions in dependencyManagement sections in the parent/aggregate POMs and use a property for the version number.

I want to cleanly update the property with the version number on frontend, preferably arbitrarily, but I can live with requiring a live upstream version to match. I've tried using versions:update-property, but that goal seems to be completely non-functional; regardless of whether there's actually a matching upstream version, I get this debug output:

$ mvn versions:update-property -Dproperty=frontend.version -DnewVersion=0.13.2  -DautoLinkItems=false -X
...
[DEBUG] Searching for properties associated with builders
[DEBUG] Property ${frontend.version}
[DEBUG] Property ${frontend.version}: Looks like this property is not associated with any dependency...
[DEBUG] Property ${frontend.version}: Set of valid available versions is [0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 0.10.0, 0.10.1, 0.11.0, 0.12.0, 0.13.0, 0.13.1, 0.13.2, 0.13.3]
[DEBUG] Property ${frontend.version}: Restricting results to 0.13.2
[DEBUG] Property ${frontend.version}: Current winner is: null
[DEBUG] Property ${frontend.version}: Searching reactor for a valid version...
[DEBUG] Property ${frontend.version}: Set of valid available versions from the reactor is []
[INFO] Property ${frontend.version}: Leaving unchanged as 0.13.1
[INFO] ------------------------------------------------------------------------

I've specified -DautoLinkItems=false, and this appears to have no effect; versions-maven-plugin still scans all of my POMs for matching dependencies, throws up its hands, and quits. I've also tried setting searchReactor to false for that property in the plugin configuration. It appears that the plugin (1) incorrectly scans the dependencies even when I've explicitly said to ignore them and (2) even filters out an explicit specific match.

Is there a simple way to rewrite a Maven property entry to a specific value, either forcing versions-maven-plugin to do what I say without validating for a version number or by using another goal? I'd prefer to avoid a tool like sed that doesn't understand XML (as I've seen recommended in a similar question), but I would be okay with a simple XPath manipulation.

chrylis -cautiouslyoptimistic-
  • 75,269
  • 21
  • 115
  • 152
  • 2
    Did you ever figure out a workable solution to this? I'm struggling with the exact same issue where update-property doesn't actually update properties – user2093082 May 08 '15 at 16:40
  • 1
    I encounter the similar issue with `versions:update-properties` with versions org.codehaus.mojo:versions-maven-plugin:2.2, 2.3 seems to fix this problem. – Ding-Yi Chen Sep 13 '16 at 08:27

7 Answers7

47

Is there a simple way to rewrite a Maven property entry to a specific value

Since version 2.5 we can use set-property (documentation):

mvn versions:set-property -Dproperty=your.property -DnewVersion=arbitrary_value

As documented, the set-property goal does not perform any 'sanity checks' on the value you specify, so it should always work, but you should use with care.

George Aristy
  • 1,373
  • 15
  • 17
  • 5
    Thanks a lot, the documentation is ridiculous. If I am not mistaken than on the documentation page of the plugin http://www.mojohaus.org/versions-maven-plugin/index.html, set-property is not mentioned - or am I blind? – JRA_TLL Apr 25 '18 at 08:09
  • @JRA_TLL You're not blind - it's not in the plugin's home page at all. Thanks for pointing it out. – George Aristy Apr 25 '18 at 13:41
  • yep.. set-property does not exist – user568021 Aug 13 '19 at 07:56
19

The newVersion parameter is badly documented (as is most of this plugin). By checking the integration tests, I see it takes a Maven version range not a simple version number. Also, it does not allow you to provide any value - it must be a valid one that Maven can resolve. The parameter would be better if it was called constrainRange

For anyone else in future, try this:

mvn versions:update-property -Dproperty=frontend.version -DnewVersion=[0.13.2]  

If you need to update to a snapshot make sure you set the property allowSnapshots to true

mvn versions:update-property -Dproperty=frontend.version -DnewVersion=[0.13.2] -DallowSnapshots=true
Community
  • 1
  • 1
drekbour
  • 2,895
  • 18
  • 28
6

How to update property in existing POM:

Try to use filtering in maven-resource-plugin:

  1. specify version in property file;
  2. add custom filter with path to this file (in child pom.xml, where dependency should be injected);
  3. update version in property file;
  4. run build.

Advantages:

  • it should work;
  • version is specified only once;
  • property file could be added under version control;
  • process-resources is one of the first maven lifecycle steps.

Disadvantages:

  • well, pom.xml still uses placeholder;
  • additional work to automatically update property file from initial build (too complicated, I suppose there should be easier solutions).

How to provide propery on build time:

You could specify any property by build parameter.

For example, I have property in my pom.xml like:

<properties>
    <build.date>TODAY</build.date>
</properties>

To change it during build I simply use parameter:

mvn compile -Dbuild.date=10.10.2010

I'm pretty sure it will work for version as well. Also, properties from top level projects are inherited by childs.

arghtype
  • 4,376
  • 11
  • 45
  • 60
  • I need to actually update the POM, not just override for a specific build. The `pom.xml` in version control should to be updated to point to the latest good upstream artifact so that development builds will know to pull it. – chrylis -cautiouslyoptimistic- Jul 30 '14 at 11:25
  • hm, it seems like resource-plugin actually allows to set values several times, I will update my answer about it. – arghtype Jul 30 '14 at 11:43
2

I had the same problem and found nothing that changes pom properties in the file. I ended up using sed like you suggested:

cat pom.xml | sed -e "s%<util.version>0.0.1-SNAPSHOT</util.version>%<util.version>$bamboo_planRepository_branch</util.version>%" > pom.xml.transformed;
rm pom.xml;
mv pom.xml.transformed pom.xml;
mojoo-de
  • 501
  • 5
  • 20
2

The following applies to versions:update-properties goal. I think the same would apply to versions:update-property.

The goal by default only works if a corresponding property definition and dependency declaration appear in the same POM file.

If, say, the property is defined in a project POM but used in a dependency declaration in a module POM, then the following config is required in the project POM for automatic update via Versions plugin.

  <properties>
    <my.version>3.7.11</my.version>
  </properties>
...

  <build>
    <plugins>
      <plugin>
         <groupId>org.codehaus.mojo</groupId>
         <artifactId>versions-maven-plugin</artifactId>
         <version>2.2</version>
         <configuration>
           <properties>
            <property>
              <name>my.version</name>
              <dependencies>
                <dependency>
                  <groupId>com.acme.test</groupId>
                  <artifactId>demo-arti</artifactId>
                </dependency>
              </dependencies>
            </property>
          </properties>
        </configuration>
      </plugin>
    </plugins>
  </build>

The plugin configuration comes into action when the Versions maven plugin runs against the POM and attempts to update the property. The configuration tells the Versions plugin that the property will be used for the stated dependency "in a POM somewhere" even if not in the present POM.

Darren Yeats
  • 101
  • 1
  • 3
  • This worked perfectly, thanks. In my case I was setting the version to be the `${project.version}`, then setting it in child poms to be `${project.parent.version}`, but it would not work for grand-children, since the parent version would be evaluated relatively – lyma Apr 29 '20 at 21:38
2

I had issue with update-property, but managed to make it work with set-property:

mvn versions:set-property -Dproperty=mypropery -DnewVersion=myvalue
Panciz
  • 2,183
  • 2
  • 30
  • 54
  • if I specify -DnewVersion=1.0.2 then below error comes: "Unknown lifecycle phase ".0.2". You must specify a valid lifecycle phase or" – c.sankhala Mar 23 '22 at 13:07
  • You have to add "" around it mvn versions:set-property -Dproperty="properties.revision" -DnewVersion="1.0.2" – Alao Nov 14 '22 at 18:47
  • is there any way to set multiple property values with different versions? – Indra Yadav Jun 08 '23 at 08:40
0

When you define your property in the pom.xml you must declare as an interval if you want that update-property works.

I mean, sure your frontend.version is defined as follow:

<frontend.version>0.13.1</frontend.version>

Then the plugin when you set -DnewVersion=0.13.2 does not recognise the value as valid value. Instead of if you define as a interval, the plugin works.

<frontend.version>[0.13.0,0.13.2]</frontend.version>

In one of my test i get the following result:

mvn versions:update-property -Dproperty=absis.version -DnewVersion=[2.20.4] -X


    [DEBUG] Property ${test.version}: Set of valid available versions is [2.19.0-RC-REVISION-1, 2.19.0-RC0.1, 2.19.0-RC0.2, 2.19.0-RC0.3, 2.19.0-RC0.4, 2.19.0-RC0.5, 2.19.0-RC0.6, 2.19.0-RC0.7, 2.19.0-RC1, 2.19.0-RC2, 2.19.0-RC3, 2.19.0, 2.19.0-revision, 2.19.0-revision2, 2.19.0.2, 2.19.1, 2.19.2, 2.19.3, 2.19.4, 2.20.0-RC0, 2.20.0-RC0.1, 2.20.0-RC1, 2.20.0-RC2, 2.20.0-RC3, 2.20.0, 2.20.0-PRUEBA-VERSION, 2.20.0-PRUEBA-VERSION-2, 2.20.0-PRUEBA-VERSION-3, 2.20.0i-RC1, 2.20.0i-RC1.1, 2.20.0i, 2.20.0i.2, 2.20.1, 2.20.2, 2.20.4, 2.20.5, 2.20.5-LT, 2.20.5.1, 2.20.6i-RC1, 2.21.0-RCtest1, 2.21.0-RCtest2]
[DEBUG] Property ${test.version}: Restricting results to [2.20.4,2.20.4]
[DEBUG] Property ${test.version}: Current winner is: 2.20.4
[DEBUG] Property ${test.version}: Searching reactor for a valid version...
[DEBUG] Property ${test.version}: Set of valid available versions from the reactor is []
[INFO] Updated ${test.version} from [2.19.0,2.21.0-SNAPSHOT] to 2.20.4

Buy you need to change the property value to a range.

It's a shame because I can't use range in my poms definition.