Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1
    • Fix Version/s: 3.2.4
    • Component/s: Dependencies, POM
    • Labels:
      None
    • Environment:
      eclipse linux xp
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      early versions, we define modules versions with expressions, and set them to the parent pom,
      simply;

      <properties>
      		<ibb-core-cache.version>1.0.1</ibb-core-cache.version>
      		<ibb-core-util.version>1.0.1</ibb-core-util.version>
      </properties>
      

      and then, we give this property to modules pom as expression ,

      	<name>ik-plug</name>
      	<packaging>jar</packaging>
      	<version>${ibb-core-util.versionn}</version>
      

      but know , it gives an error you know like this,

      [WARNING] Some problems were encountered while building the effective model for ibb-parent:ibb-modules-parent:pom:1.0.0
      [WARNING] 'version' contains an expression but should be a constant. @ ibb-parent:ibb-modules-parent:${ibb-core-jars.version}, C:\dev\ibb\workspace\core\ibb-modules-parent\pom.xml
      

      but I think that, this enhancement is causes wrong result,

      think that , if we have i project already developing about 3 years, this project has a lot of modules, and this modules have sub modules , and this sub modules already bound to some other modules not define in your pom, but your updates must be affect them, at this situation, developer want to write the existing version numbers with properties to parent pom, and want to manage them like this. at the attach file below , the close projects are belongs to open projects, but they are the different team developing this. I cant force the other developers to cache their versions, I must use this versions as initial step

        Issue Links

          Activity

          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.
          Hide
          Axel Fontaine added a comment -

          I also believe expressions should be allowed.

          This enables you to decouple updating your version number from checking in to version control, which is one of the big problems with the traditional Maven release process.

          This way, the only change actually commited for a new release is the code. No need to additionally modify the POM.

          I've described this in detail here: http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html

          Show
          Axel Fontaine added a comment - I also believe expressions should be allowed. This enables you to decouple updating your version number from checking in to version control, which is one of the big problems with the traditional Maven release process. This way, the only change actually commited for a new release is the code. No need to additionally modify the POM. I've described this in detail here: http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html
          Hide
          Don Brown added a comment -

          Agreed. I've started converting projects to not have the version hard-coded in the poms and it has done wonders to development speed and flexibility, especially in a continuous deployment environment.

          Show
          Don Brown added a comment - Agreed. I've started converting projects to not have the version hard-coded in the poms and it has done wonders to development speed and flexibility, especially in a continuous deployment environment.
          Hide
          Nicolas Grobisa added a comment -

          I agree with Axel Fontaine and Don Brown. I have been investigating this problem for some time now.
          I believe Maven is taking a wrong turn here. I understand why they want to do it: Basically, if you allow version expressions, you may endanger reproducibility, but this cannot be a restriction. In any case, it should be a configurable warning/error. This restriction is a major barrier for people wanting to do continuous delivery.
          The essence of the problem comes from Maven wanting to do everything. In some ways, it is analog to storing the SCM URL inside the POM. For many reasons and in different scenarios, some of the POM information should be kept outside the POM, or at least provide the flexibility for users to do it one way or the other.

          Show
          Nicolas Grobisa added a comment - I agree with Axel Fontaine and Don Brown. I have been investigating this problem for some time now. I believe Maven is taking a wrong turn here. I understand why they want to do it: Basically, if you allow version expressions, you may endanger reproducibility, but this cannot be a restriction. In any case, it should be a configurable warning/error. This restriction is a major barrier for people wanting to do continuous delivery. The essence of the problem comes from Maven wanting to do everything. In some ways, it is analog to storing the SCM URL inside the POM. For many reasons and in different scenarios, some of the POM information should be kept outside the POM, or at least provide the flexibility for users to do it one way or the other.
          Hide
          Cameron Rochester added a comment -

          We are also using a centralised list of version properties for managing our multi-module build. At last count we have about 50 modules each with independent versions. There doesn't seem to be anyway to manage versions in a centralised manner beyond this approach. I also think Maven needs to reconsider where they are going with this approach.

          Show
          Cameron Rochester added a comment - We are also using a centralised list of version properties for managing our multi-module build. At last count we have about 50 modules each with independent versions. There doesn't seem to be anyway to manage versions in a centralised manner beyond this approach. I also think Maven needs to reconsider where they are going with this approach.
          Hide
          Nathaniel Mishkin added a comment -

          FWIW, my use case for using properties in specifying the <version> for a project's component is this: I've created a project whose sole purpose in life is to create a variant (in this case, signed) of an existing artifact that's not mine (not produced by any of my projects). In the variant project I've created I want to do something like this:

          <project>
          <properties>
          <x.version>4.32</x.version>
          </properties>

          <dependencies>
          <dependency>
          <groupId>...</groupId>
          <artifactId>x</artifactId>
          <version>$

          {x.version}</version>
          </dependency>
          </dependencies>

          <groupId>...</groupId>
          <artifactId>x.variant</artifactId>
          <version>${x.version}

          </version>
          ...
          </project>

          (In real life the property definition is specified an ancestor POM.)

          Show
          Nathaniel Mishkin added a comment - FWIW, my use case for using properties in specifying the <version> for a project's component is this: I've created a project whose sole purpose in life is to create a variant (in this case, signed) of an existing artifact that's not mine (not produced by any of my projects). In the variant project I've created I want to do something like this: <project> <properties> <x.version>4.32</x.version> </properties> <dependencies> <dependency> <groupId>...</groupId> <artifactId>x</artifactId> <version>$ {x.version}</version> </dependency> </dependencies> <groupId>...</groupId> <artifactId>x.variant</artifactId> <version>${x.version} </version> ... </project> (In real life the property definition is specified an ancestor POM.)
          Hide
          Michael Osipov added a comment -

          How does that happen? I do not get this with Maven 3.1.1.

          Show
          Michael Osipov added a comment - How does that happen? I do not get this with Maven 3.1.1.
          Hide
          Esteban Porcelli added a comment -

          We have several big modules/repositories with many branches. Per repository we have one parent pom and 50+ children poms.
          This is for a large JEE project (1 million lines of code) that it is delivered to several different clients.

          We need to create feature branches, bug fixes, integration branches, release branches etc. We have many versions of the same application deployed to different production environments.

          Every time a new branch is created, the version tag in the parent pom and all children poms need to be updated (versions plugin helps).
          When these branches need to be merged all these poms cause conflicts and they need to be manually resolved, because some times there are other changes in the poms besides just the version change. It is a major problem for us.

          We need to change the version on every branch because we have a continuous integration server that builds every branch and runs regression tests against every branch, therefore the versions must be different per branch.

          Being able to keep the new version isolated to one file (the parent pom) really makes sense here. (Child pom inherits version from parent property)

          The continuous delivery solution discussed in this issue would not work for us. We need to use SNAPSHOTS as we cannot have every developer build the whole system. Developers need to use artifacts built by Jenkins for their feature branch and they cannot be changing to the last build version they depend on every time a new development build is created.

          I hope this scenario pushes the maven team to consider this issue more seriously. This issue and other similar issues have been around for many many years.

          Show
          Esteban Porcelli added a comment - We have several big modules/repositories with many branches. Per repository we have one parent pom and 50+ children poms. This is for a large JEE project (1 million lines of code) that it is delivered to several different clients. We need to create feature branches, bug fixes, integration branches, release branches etc. We have many versions of the same application deployed to different production environments. Every time a new branch is created, the version tag in the parent pom and all children poms need to be updated (versions plugin helps). When these branches need to be merged all these poms cause conflicts and they need to be manually resolved, because some times there are other changes in the poms besides just the version change. It is a major problem for us. We need to change the version on every branch because we have a continuous integration server that builds every branch and runs regression tests against every branch, therefore the versions must be different per branch. Being able to keep the new version isolated to one file (the parent pom) really makes sense here. (Child pom inherits version from parent property) The continuous delivery solution discussed in this issue would not work for us. We need to use SNAPSHOTS as we cannot have every developer build the whole system. Developers need to use artifacts built by Jenkins for their feature branch and they cannot be changing to the last build version they depend on every time a new development build is created. I hope this scenario pushes the maven team to consider this issue more seriously. This issue and other similar issues have been around for many many years.

            People

            • Assignee:
              Jason van Zyl
              Reporter:
              Faruk
            • Votes:
              58 Vote for this issue
              Watchers:
              50 Start watching this issue

              Dates

              • Created:
                Updated: