Maven
  1. Maven
  2. MNG-4297

Disallow use of properties in the project coordinates

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: POM
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      Maven currently allows properties in the groupId, artifactId and version of a pom. This causes artifacts to be produced that require full inheritance and interpolation before they can be uniquely identified. It also poses potential problems if the properties are defined in settings, env or profiles where the consumer can't exactly identify the artifact after the fact.

      Allowing properties in the coordinates generally allows bad practices. After all, how can you not know what the identify of the project you're working on actually is?

        Issue Links

          Activity

          Hide
          Benjamin Bentmann added a comment -

          Made Maven 3.0 produce a model problem with severity WARNING for this in r803995 to inform users that this might finally be prohibited in the future.

          Show
          Benjamin Bentmann added a comment - Made Maven 3.0 produce a model problem with severity WARNING for this in r803995 to inform users that this might finally be prohibited in the future.
          Hide
          Bruno F added a comment -

          Please don't disallow properties in the classifier since it is the only smart way (please tell me if you know any other possibility) to handle native code, JNI stuff, etc. Disallow anywhere but not in the classifier.

          This enables to group a jar and its associated JNI libraries into identifiable artifacts:
          mygroupid:jniartifact:1.3:zip:bin-x86-linux2.6-gcc3.3
          mygroupid:jniartifact:1.3:zip:bin-x86-windows-vc8

          This also enables to declare native dependencies for the JNI code:
          <dependency>
          <groupId>boost</groupId>
          <artifactId>boost_regex</artifactId>
          <version>$

          {boost.version}

          </version>
          <classifier>bin-$

          {target.platform}

          </classifier>
          <type>zip</type>
          </dependency>
          Where target platform is defined by profile and shall be set to x86-linux2.6-gcc3.3 on linux or bin-x86-windows-vc8 on windows.

          Show
          Bruno F added a comment - Please don't disallow properties in the classifier since it is the only smart way (please tell me if you know any other possibility) to handle native code, JNI stuff, etc. Disallow anywhere but not in the classifier. This enables to group a jar and its associated JNI libraries into identifiable artifacts: mygroupid:jniartifact:1.3:zip:bin-x86-linux2.6-gcc3.3 mygroupid:jniartifact:1.3:zip:bin-x86-windows-vc8 This also enables to declare native dependencies for the JNI code: <dependency> <groupId>boost</groupId> <artifactId>boost_regex</artifactId> <version>$ {boost.version} </version> <classifier>bin-$ {target.platform} </classifier> <type>zip</type> </dependency> Where target platform is defined by profile and shall be set to x86-linux2.6-gcc3.3 on linux or bin-x86-windows-vc8 on windows.
          Hide
          Benjamin Bentmann added a comment -

          A classifier is not a project coordinate.

          Show
          Benjamin Bentmann added a comment - A classifier is not a project coordinate.
          Hide
          Tristan ROBET added a comment -

          What about inheritance ? Isn't it a good pratice to put <version>$

          {parent.project.version}

          </version> in each child project ?

          Show
          Tristan ROBET added a comment - What about inheritance ? Isn't it a good pratice to put <version>$ {parent.project.version} </version> in each child project ?
          Hide
          Benjamin Bentmann added a comment -

          Isn't it a good pratice to put <version>${parent.project.version}</version> in each child project ?

          Nope, because it's redundant, just omit the version in the child and it uses the parent version.

          Show
          Benjamin Bentmann added a comment - Isn't it a good pratice to put <version>${parent.project.version}</version> in each child project ? Nope, because it's redundant, just omit the version in the child and it uses the parent version.
          Hide
          Chris Price added a comment -

          I think there are valid use cases where expressions should be able to be used as version numbers. At least until mix-ins become available, using expressions for version numbers allows us to keep our poms DRY in ways that would be impossible otherwise.

          For example, we have the following:

          • A super POM that EVERYTHING inherits from
          • A "jar" pom that contains settings that we use on our "standard" jars
          • A "swc" pom that contains settings we use on swcs.

          We have two projects that we release, let's call them "Project A" and "Project B". Both are multimodule projects and contain both jars and swcs.

          Right now, we keep version number constants in the super POM, like:

          <properties>
          <version.project-a>3.1-SNAPSHOT</version.project-b>
          <version.project-b>7.3-SNAPSHOT</version.project-b>
          </properties>

          Using this pattern, poms from A and B can inherit from the jar/swc parent poms accordingly, and just specify $

          {version.project-a}

          for their version number. And there is NOTHING that we have to maintain in more than one place.

          If we have to have a single "project-a" parent pom that explicitly specifies a version number, then we are going to have to have the jar/swc parent poms inherit from that one, and then have the real modules inside of project a inherit from those. And we'll have to maintain another copy of those jar/swc poms for project b. With mix-ins we should be able to eliminate that redundancy, but until then, we are faced with the choice of using expressions for the version numbers or duplicating all of the content of our jar/swc poms, and the expressions path seems MUCH more manageable.

          Show
          Chris Price added a comment - I think there are valid use cases where expressions should be able to be used as version numbers. At least until mix-ins become available, using expressions for version numbers allows us to keep our poms DRY in ways that would be impossible otherwise. For example, we have the following: A super POM that EVERYTHING inherits from A "jar" pom that contains settings that we use on our "standard" jars A "swc" pom that contains settings we use on swcs. We have two projects that we release, let's call them "Project A" and "Project B". Both are multimodule projects and contain both jars and swcs. Right now, we keep version number constants in the super POM, like: <properties> <version.project-a>3.1-SNAPSHOT</version.project-b> <version.project-b>7.3-SNAPSHOT</version.project-b> </properties> Using this pattern, poms from A and B can inherit from the jar/swc parent poms accordingly, and just specify $ {version.project-a} for their version number. And there is NOTHING that we have to maintain in more than one place. If we have to have a single "project-a" parent pom that explicitly specifies a version number, then we are going to have to have the jar/swc parent poms inherit from that one, and then have the real modules inside of project a inherit from those. And we'll have to maintain another copy of those jar/swc poms for project b. With mix-ins we should be able to eliminate that redundancy, but until then, we are faced with the choice of using expressions for the version numbers or duplicating all of the content of our jar/swc poms, and the expressions path seems MUCH more manageable.
          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
          Hide
          Jason van Zyl 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
          Jason van Zyl 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:
              brianfox brianfox
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: