Maven Shared Components
  1. Maven Shared Components
  2. MSHARED-40

Exported POM still has dependency version ranges

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: maven-archiver
    • Labels:
      None
    • Number of attachments :
      0

      Description

      If you have a version range for one of your dependencies, then the exported POM (the one that's placed in the repository and in the jar itself) will still have a range there. This seems at odds with (one) point of exporting a POM, which is to have all the information you need to reconstruct the state of a build at a particular moment in time. Without knowing which version number was chosen, you can't be sure you're reconstructing the same build later.

      It also seems to be at odds with the behavior elsewhere in this exported artifact: the plugins section shows the actual version number used, and active profiles are quietly merged into the main POM.

        Activity

        Hide
        Pether Sorling added a comment -

        Have the same issue with with some values not evaluated in the dependency part of the exported pom, using a profile like the one below the determine a version number in dependencies.

        <profile>
        <id>developer</id>
        <properties>
        <version.qualifier>DEV-20060709</version.qualifier>
        </properties>
        </profile>

        <dependency>
        <groupId>some.group</groupId>
        <artifactId>fnord</artifactId>
        <version>0.1.0-$

        {version.qualifier}

        </version>
        </dependency>

        Evaluates correctly during build but the exported pom contains the same version string as above unevaluated.

        Show
        Pether Sorling added a comment - Have the same issue with with some values not evaluated in the dependency part of the exported pom, using a profile like the one below the determine a version number in dependencies. <profile> <id>developer</id> <properties> <version.qualifier>DEV-20060709</version.qualifier> </properties> </profile> <dependency> <groupId>some.group</groupId> <artifactId>fnord</artifactId> <version>0.1.0-$ {version.qualifier} </version> </dependency> Evaluates correctly during build but the exported pom contains the same version string as above unevaluated.
        Hide
        Carlos Sanchez added a comment -

        it'd be good if help:effective-pom (or maybe a new goal) reflects also the pom after resolution, with locked down versions

        Show
        Carlos Sanchez added a comment - it'd be good if help:effective-pom (or maybe a new goal) reflects also the pom after resolution, with locked down versions
        Hide
        Thorsten Möller added a comment -

        My experience is that any occurrence of properties is not substituted in exported POMs. It seems to me that the original POM files are merely copied. Is this correct? Maybe the Maven experts on this board can shed a light whether this is intended behavior and (ii) whether there can be harmful consequences caused by the fact that properties are not evaluated.

        Show
        Thorsten Möller added a comment - My experience is that any occurrence of properties is not substituted in exported POMs. It seems to me that the original POM files are merely copied. Is this correct? Maybe the Maven experts on this board can shed a light whether this is intended behavior and (ii) whether there can be harmful consequences caused by the fact that properties are not evaluated.
        Hide
        Michael Osipov added a comment -

        Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

        Show
        Michael Osipov added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          People

          • Assignee:
            Unassigned
            Reporter:
            Matthew Beermann
          • Votes:
            4 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: