Maven
  1. Maven
  2. MNG-2199

Support version ranges in parent elements

    Details

    • Complexity:
      Intermediate
    • Number of attachments :
      9

      Description

      It would be great if Maven supports version ranges when specifying parent artifacts in a multi-module build. Currently this does not work.

        <parent>
          <artifactId>artifactId</artifactId>
          <groupId>groupId</groupId>
          <version>[2.0, 2.0.1]</version>
        </parent>
      [INFO] Scanning for projects...
      Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 2.0.1]/artifactId-[2.0, 2.0.1].pom

      Additionally it would be great if this

        <parent>
          <artifactId>artifactId</artifactId>
          <groupId>groupId</groupId>
          <version>[2.0, ${pom.version}]</version>
        </parent>
      [INFO] Scanning for projects...
      Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, ${pom.version}]/artifactId-[2.0, ${pom.version}].pom

      would also work, if the version is specified in the same pom.xml which defines this parent definition.

      1. MNG-2199.patch
        24 kB
        Christian Schulte
      2. MNG-2199.patch
        23 kB
        Christian Schulte
      3. MNG-2199.patch
        16 kB
        Christian Schulte
      4. MNG-2199.patch
        16 kB
        Christian Schulte
      5. MNG-2199.patch
        16 kB
        Christian Schulte
      6. MNG-2199.patch
        10 kB
        Christian Schulte
      7. MNG-2199-3.0.4.patch
        23 kB
        Christian Schulte
      8. MNG-2199-3.0.4.patch
        22 kB
        Christian Schulte
      9. MNG-2199-3.1.0-alpha-1.patch
        29 kB
        Christian Schulte

        Issue Links

          Activity

          Hide
          Christian Schulte added a comment -

          Updated patches to handle unavailable versions for a given range.

          Show
          Christian Schulte added a comment - Updated patches to handle unavailable versions for a given range.
          Hide
          Benjamin Busjaeger added a comment - - edited

          I believe version ranges in parent POMs should be supported, because they enable an important usage pattern of maven.

          I understand the argument for keeping the parent version a fixed quantity. It makes it possible to store the build repository URL in the parent POM, thus eliminating the need for an external settings file. This makes builds self-contained and reproducible.

          However, I would argue that this pattern only works well for small maven projects, because it has several implications. First, it implies that whenever the parent POM version is updated, all POMs referencing it must be updated as well with the new version. This greatly reduces the ability to do partial builds, because each time the parent changes all projects referencing it change as well. Second, assuming the parent POM contains the repository URL, it must always be checked out along with the remaining source code. In large multi-module projects developers may only check out the part of the source tree that's relevant to them. Finally, it assumes developers actually update the parent version when they make a change. If they forget to do it, CI builds that perform the deployment will fail, because the parent versions already exist. In large, loosely-coupled development organization such an assumption cannot be made.

          Using version ranges in parent references along with the following usage pattern can alleviate this problem:

          • store each parent version in a separate repository
          • point to the parent repository in the settings file
          • whenever going to an older source version, delete cached parent artifact in ./m2

          Note that the parent repository URL in the settings file could be derived from the current source version to keep builds reproducible. The process can also be automated to ease the burden on developers. Furthermore, since the parent references specify ranges, the CI system can automatically append a unique (and increasing) qualifier when deploying the parent to eliminate the assumption that developers will update the parent version.

          Now it could be argued that in development parent references should use snapshot versions. Apart from the fact that snapshot version have their own issues when it comes to large-scale projects, this argument would be self-contradicting in this context, since snapshots are version ranges of the form "version-[beginning of time, end of time]".

          Show
          Benjamin Busjaeger added a comment - - edited I believe version ranges in parent POMs should be supported, because they enable an important usage pattern of maven. I understand the argument for keeping the parent version a fixed quantity. It makes it possible to store the build repository URL in the parent POM, thus eliminating the need for an external settings file. This makes builds self-contained and reproducible. However, I would argue that this pattern only works well for small maven projects, because it has several implications. First, it implies that whenever the parent POM version is updated, all POMs referencing it must be updated as well with the new version. This greatly reduces the ability to do partial builds, because each time the parent changes all projects referencing it change as well. Second, assuming the parent POM contains the repository URL, it must always be checked out along with the remaining source code. In large multi-module projects developers may only check out the part of the source tree that's relevant to them. Finally, it assumes developers actually update the parent version when they make a change. If they forget to do it, CI builds that perform the deployment will fail, because the parent versions already exist. In large, loosely-coupled development organization such an assumption cannot be made. Using version ranges in parent references along with the following usage pattern can alleviate this problem: store each parent version in a separate repository point to the parent repository in the settings file whenever going to an older source version, delete cached parent artifact in ./m2 Note that the parent repository URL in the settings file could be derived from the current source version to keep builds reproducible. The process can also be automated to ease the burden on developers. Furthermore, since the parent references specify ranges, the CI system can automatically append a unique (and increasing) qualifier when deploying the parent to eliminate the assumption that developers will update the parent version. Now it could be argued that in development parent references should use snapshot versions. Apart from the fact that snapshot version have their own issues when it comes to large-scale projects, this argument would be self-contradicting in this context, since snapshots are version ranges of the form "version- [beginning of time, end of time] ".
          Hide
          Christian Schulte added a comment -

          Patch for Maven 3.1.0-alpha-1. Final version.

          Show
          Christian Schulte added a comment - Patch for Maven 3.1.0-alpha-1. Final version.
          Hide
          Jason van Zyl added a comment -

          I was looking at this patch this week but there are no tests. If you create a pull request on Github for the core, and a pull request for the integration tests and everything passes I will process this patch. For reference you may want to take a look at : http://takari.io/2014/06/02/contributing-to-maven-core.html

          Show
          Jason van Zyl added a comment - I was looking at this patch this week but there are no tests. If you create a pull request on Github for the core, and a pull request for the integration tests and everything passes I will process this patch. For reference you may want to take a look at : http://takari.io/2014/06/02/contributing-to-maven-core.html
          Hide
          Jason van Zyl added a comment -

          Fixed on 045bd1503b70738ffd0fa08e336574107aded801

          Show
          Jason van Zyl added a comment - Fixed on 045bd1503b70738ffd0fa08e336574107aded801

            People

            • Assignee:
              Jason van Zyl
              Reporter:
              Christian Schulte
            • Votes:
              26 Vote for this issue
              Watchers:
              31 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: