Mojo's Versions Maven Plugin
  1. Mojo's Versions Maven Plugin
  2. MVERSIONS-123

Version properties inparent not picked up by e.g. display-property-updates

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: 1.2
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Windows XP
      Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
      Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)
    • Number of attachments :
      1

      Description

      The goals operating on property controlled version numbers (e.g. display-property-updates) only work if the properties are defined in the targeted POM itself, not in a parent POM.

      Example:

      If module B has a dependency on module A, declared in B as follows:

      <dependency>
      <groupId>com.my.test</groupId>
      <artifactId>module-A</artifactId>
      <version>$

      {module-A.version}</version>
      </dependency>

      but ${module-A.version}

      is not defined in B's own POM, but its parent, then the plugin doesn't pick it up - it simply says:

      "This project does not have any properties associated with versions"

      This is a major problem for us, since all our dependency version properties are defined in each project's root POM, i.e. the parent of all sub-modules in that project.

        Activity

        Hide
        Gagandeep added a comment -

        Given that this plugin doesn't support what Cornel Masson wants, can you suggest some code to find the dependency in a submodule when the corresponding version property is defined in the parent pom? The "wnr" and "as" object under returns nothing when the property is defined in the parent pom. Any way around to actually update the property even if it's defined in parent?

        ArtifactVersion wnr = version.getNewestVersion( currentVersion, property, this.allowSnapshots, this.reactorProjects, this.getHelper() );
        ArtifactAssociation[] as = version.getAssociations();

        Show
        Gagandeep added a comment - Given that this plugin doesn't support what Cornel Masson wants, can you suggest some code to find the dependency in a submodule when the corresponding version property is defined in the parent pom? The "wnr" and "as" object under returns nothing when the property is defined in the parent pom. Any way around to actually update the property even if it's defined in parent? ArtifactVersion wnr = version.getNewestVersion( currentVersion, property, this.allowSnapshots, this.reactorProjects, this.getHelper() ); ArtifactAssociation[] as = version.getAssociations();
        Hide
        Andrei Ivanov added a comment -

        Any chance to get this usage pattern supported too?
        AFAIK it's pretty common and I've just been bitten by this

        Show
        Andrei Ivanov added a comment - Any chance to get this usage pattern supported too? AFAIK it's pretty common and I've just been bitten by this
        Hide
        Sergei Ivanov added a comment -

        This also bugged me for quite a long time in our reactor projects. Whenever I moved all properties into the top-level reactor POM (which was a parent of all other modules in the reactor), then there were no applicable property updates reported by v-m-p for the children projects.

        The only way to solve this was to introduce dependencyManagement alongside properties in the parent/aggregator POM and declare all dependencies (with property placeholders for versions) there. Then child POMs were able to drop the version specification on dependency element altogether, and let the parent manage it. That way, running versions:display-property-updates on the top-level POM would display all applicable property updates. However, this approach did not solve the problem of detecting the property updates if the properties were inherited from a distant parent POM, which was not part of the reactor.

        @Stephen:
        When you are saying that

        if there is no property defined in B then there are no updates that can be made in B so when you run the goal within the scope of the B project only, then there is nothing to do.

        ...you are not entirely correct. One has an option to introduce a local property in B, thus overriding the inherited value.

        It would perhaps make sense to make a distinction between referenced local and non-local (inherited) properties and produce version update reports for both. It might also be helpful, if the report indicated which parent project the non-local property was inherited from. Not sure how difficult (or feasible) that would be technically, so please forgive me if I am pushing it too far.

        Show
        Sergei Ivanov added a comment - This also bugged me for quite a long time in our reactor projects. Whenever I moved all properties into the top-level reactor POM (which was a parent of all other modules in the reactor), then there were no applicable property updates reported by v-m-p for the children projects. The only way to solve this was to introduce dependencyManagement alongside properties in the parent/aggregator POM and declare all dependencies (with property placeholders for versions) there. Then child POMs were able to drop the version specification on dependency element altogether, and let the parent manage it. That way, running versions:display-property-updates on the top-level POM would display all applicable property updates. However, this approach did not solve the problem of detecting the property updates if the properties were inherited from a distant parent POM, which was not part of the reactor. @Stephen: When you are saying that if there is no property defined in B then there are no updates that can be made in B so when you run the goal within the scope of the B project only, then there is nothing to do. ...you are not entirely correct. One has an option to introduce a local property in B, thus overriding the inherited value. It would perhaps make sense to make a distinction between referenced local and non-local (inherited) properties and produce version update reports for both. It might also be helpful, if the report indicated which parent project the non-local property was inherited from. Not sure how difficult (or feasible) that would be technically, so please forgive me if I am pushing it too far.
        Hide
        Stephen Connolly added a comment -

        One has an option to introduce a local property in B, thus overriding the inherited value.

        And as soon as you add the property override to B then the plugin should start showing updates for that property... and if it isn't then that is a bug.

        This is like the difference between versions:set acting on the parent of the following two poms

        <project>
          <parent>
            <groupId>local</groupId>
            <artifactId>parent</artifactId>
            <version>1.0-SNAPSHOT</version>
          </parent>
          <artifactId>child-a</artifactId>
        </project>
        
        <project>
          <parent>
            <groupId>local</groupId>
            <artifactId>parent</artifactId>
            <version>1.0-SNAPSHOT</version>
          </parent>
          <artifactId>child-b</artifactId>
          <version>1.0-SNAPSHOT</version>
        </project>
        

        When versions:set is run against local:parent:1.0-SNAPSHOT then both child projects will have their /project/parent/version updated. child-b, by providing an explicit /project/version value is indicating the intent that it should not be versioned in lock step with the parent.

        I appreciate that it can be confusing to understand why the plugin makes the inferences that it does... but in general the principle is that if you have repeated something that you don't need to repeat then that indicates the repetition is important to you.

        So now we get to what should you be doing?

        Well if you are defining the version of a single dependency, you should not use a property to control it (except for the very rare case where you want to test different versions of the dependency quickly from the CLI... but that is rare)

        So the correct case to use a property is where you have multiple dependencies that must be kept in lock step. You are asking for errors if you don't handle that with a dependencyManagement in the same pom as where the property is defined... so while I view it as a bug that the parent does not check the child projects from the reactor for use of the property, it is not really a fixable bug as there is no way to guarantee - from the parent - that its only children are those within the reactor... a better way to handle this is to view projects that explicitly use a property inherited from their parent, rather than having the dependency management inherited, as being stylistically incorrect.

        This plugin is opinionated. Its opinion is that you did not specify any properties in the pom and thus there are no properties in the pom to update... I think - unchecked - that you could indicate your intent by adding

        ...
        <properties>
          <foo.version>${foo.version}</foo.version>
          ...
        </properties>
        ...
        

        in other words by indicating that the property's default value is the same as the parents but you want the option to change from the default

        Show
        Stephen Connolly added a comment - One has an option to introduce a local property in B, thus overriding the inherited value. And as soon as you add the property override to B then the plugin should start showing updates for that property... and if it isn't then that is a bug. This is like the difference between versions:set acting on the parent of the following two poms <project> <parent> <groupId>local</groupId> <artifactId>parent</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>child-a</artifactId> </project> <project> <parent> <groupId>local</groupId> <artifactId>parent</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>child-b</artifactId> <version>1.0-SNAPSHOT</version> </project> When versions:set is run against local:parent:1.0-SNAPSHOT then both child projects will have their /project/parent/version updated. child-b , by providing an explicit /project/version value is indicating the intent that it should not be versioned in lock step with the parent. I appreciate that it can be confusing to understand why the plugin makes the inferences that it does... but in general the principle is that if you have repeated something that you don't need to repeat then that indicates the repetition is important to you. So now we get to what should you be doing? Well if you are defining the version of a single dependency, you should not use a property to control it (except for the very rare case where you want to test different versions of the dependency quickly from the CLI... but that is rare) So the correct case to use a property is where you have multiple dependencies that must be kept in lock step. You are asking for errors if you don't handle that with a dependencyManagement in the same pom as where the property is defined... so while I view it as a bug that the parent does not check the child projects from the reactor for use of the property, it is not really a fixable bug as there is no way to guarantee - from the parent - that its only children are those within the reactor... a better way to handle this is to view projects that explicitly use a property inherited from their parent, rather than having the dependency management inherited, as being stylistically incorrect. This plugin is opinionated. Its opinion is that you did not specify any properties in the pom and thus there are no properties in the pom to update... I think - unchecked - that you could indicate your intent by adding ... <properties> <foo.version>${foo.version}</foo.version> ... </properties> ... in other words by indicating that the property's default value is the same as the parents but you want the option to change from the default
        Hide
        Sergei Ivanov added a comment -

        I think that there are two possible views on the same problem, and that is why it is confusing to many people.

        1. How the plugin views it at the moment (to the best of my understanding):
        a) collect all properties defined locally in the POM
        b) identify which of those properties are locally used in dependency version specifications
        c) check for dependency version updates corresponding to that subset of properties

        2. How many people intuitively assume is:
        a) walk through all locally declared dependencies and dependency management in the POM
        b) extract property references from version specifications of those managed and unmanaged dependencies
        c) check for dependency version updates corresponding to that subset of properties

        The difference is that the second approach can yield a larger subset of properties, some of which might not be locally defined, but inherited.

        Before the invention of BOMs and import scope, people used inheritable properties to provide a coherent version for a large number of modules of a 3rd-party library. That saved the effort going through the hassle of setting up dependency management for each and every possibly used module in the parent POM. Think of Spring framework: one would declare the spring.version=2.5.6 property in the parent POM and let the descendant POMs refer to it when declaring dependencies on spring-beans, or spring-web, or spring-whatever. Setting up dependency management for spring-beans, spring-web, spring-whatever and a dozen other Spring libraries (some of them would never be used, but just in case) in the parent POM would be a major hassle compared to just a single property declaration. Given that provided BOMs are still rare, the problem is still actual to this day.

        Show
        Sergei Ivanov added a comment - I think that there are two possible views on the same problem, and that is why it is confusing to many people. 1. How the plugin views it at the moment (to the best of my understanding): a) collect all properties defined locally in the POM b) identify which of those properties are locally used in dependency version specifications c) check for dependency version updates corresponding to that subset of properties 2. How many people intuitively assume is: a) walk through all locally declared dependencies and dependency management in the POM b) extract property references from version specifications of those managed and unmanaged dependencies c) check for dependency version updates corresponding to that subset of properties The difference is that the second approach can yield a larger subset of properties, some of which might not be locally defined, but inherited. Before the invention of BOMs and import scope, people used inheritable properties to provide a coherent version for a large number of modules of a 3rd-party library. That saved the effort going through the hassle of setting up dependency management for each and every possibly used module in the parent POM. Think of Spring framework: one would declare the spring.version=2.5.6 property in the parent POM and let the descendant POMs refer to it when declaring dependencies on spring-beans, or spring-web, or spring-whatever. Setting up dependency management for spring-beans, spring-web, spring-whatever and a dozen other Spring libraries (some of them would never be used, but just in case) in the parent POM would be a major hassle compared to just a single property declaration. Given that provided BOMs are still rare, the problem is still actual to this day.

          People

          • Assignee:
            Unassigned
            Reporter:
            Cornel Masson
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: