Add support for property defined version update in the goal use-dep-version

[amalakar]

I noticed that currently use-dep-version works only when the version is defined inline, as in the following works:

mvn versions:use-dep-version  -DdepVersion=2.3.1 '-Dincludes=javax.xml.bind:jaxb-api'

--- a/example/pom.xml
+++ b/example/pom.xml
@@ -80,7 +80,7 @@
         <dependency>
             <groupId>javax.xml.bind</groupId>
             <artifactId>jaxb-api</artifactId>
-            <version>2.3.0</version>
+            <version>2.3.1</version>
         </dependency>

But the following property defined version doesn't get updated:

    <properties>
      <jaxb.version>2.3.0</jaxb.version>
    </properties>

        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>${jaxb.version}</version>
        </dependency>

This is a feature request to make use-dep-version work for property defined dependencies too.

Use case: we have many internal repositories which depends on few internal common libraries, sometimes we would want to update all of those repos to the latest version of the common libraries for bugs/security issues etc. But the downstream maven projects sometimes would have the version defined as a property or sometimes as inline version. If one command could handle both cases we could easily update all the repos to the target version.

[github-actions]

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[amalakar]

I am still interested in this feature/use case.

[andrzejj0]

So, the problem is that all properties are resolved (interpolated) when processed by the mojo. Whilst the is matched by the mojo, PomHelper is unable to replace the dependency version because it's unable to retrieve the sought string (containing the resolved property value) in the POM, so the POM is not getting updated.

Using a raw POM does help here; checking what the impact of changing that would be.

[andrzejj0]

Proposed new feature.

/**
 * <p>Will augment normal processing by, if a dependency value is set using a property, trying to update
 * the value of the property.</p>
 * <p>If the property value is specified directly, will process it normally (as with {@code processProperties} being
 * {@code false}. If the property being updated is redefined in the reactor tree, will only change the property
 * value which lies closest to the dependency being updated. If the same property is also used to set
 * the value of another dependency, will not update that property value, and log a warning instead. Finally,
 * if the property value is specified in a parent file which is outside
 * of the project, will log a warning message.</p>
 * <p>Default is {@code false}.</p>
 */
@Parameter(property = "processProperties", defaultValue = "false")
protected boolean processProperties;

The default value is false to retain backwards compatibility. I'd be wary of changing it.

What do you think, @slawekjaranowski @pzygielo?

[amalakar]

Thank you for supporting this use case!

[wollowizard]

Hi @amalakar and all, thanks for this feature. I do get a NullPointerException when using it:
mvn -o versions:use-dep-version -DprocessProperties=true -DdepVersion=3.0.0-SNAPSHOT -Dincludes={group}:*

Caused by: java.lang.NullPointerException
    at org.codehaus.plexus.util.StringUtils.deleteWhitespace (StringUtils.java:147)
    at org.codehaus.mojo.versions.api.PomHelper.setDependencyVersion (PomHelper.java:565)
    at org.codehaus.mojo.versions.AbstractVersionsDependencyUpdaterMojo.updateDependencyVersion (AbstractVersionsDependencyUpdaterMojo.java:536)
    at org.codehaus.mojo.versions.UseDepVersionMojo.useDepVersion (UseDepVersionMojo.java:366)
    at org.codehaus.mojo.versions.UseDepVersionMojo.processModel (UseDepVersionMojo.java:201)
    at org.codehaus.mojo.versions.UseDepVersionMojo.execute (UseDepVersionMojo.java:156)

can you confirm this is the right way to use it?

[andrzejj0]

This will be fixed in the next release. Please use -DprocessDependencies=false as a workaround.