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.6
    • 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
          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.
          Hide
          Robert Scholte added a comment -

          Based on the original example, why not use

          <properties>
              <ibb-core-cache.version>${project.version}</ibb-core-cache.version>
              <ibb-core-util.version>${project.version}</ibb-core-util.version>
          </properties>
          
              <name>ik-plug</name>
              <packaging>jar</packaging>
              <version>1.0.1</version>
          

          This should give you exactly the same result and Maven allows it.

          Show
          Robert Scholte added a comment - Based on the original example, why not use <properties> <ibb-core-cache.version> ${project.version} </ibb-core-cache.version> <ibb-core-util.version> ${project.version} </ibb-core-util.version> </properties> <name> ik-plug </name> <packaging> jar </packaging> <version> 1.0.1 </version> This should give you exactly the same result and Maven allows it.
          Hide
          Faruk added a comment -

          Hi Robert,

          I think you misunderstood my point, thank you though

          I would like to use properties instead of strict version numbers in dependencies.

          defining version numbers as properties and use this properties in dependencies helps management if you have multi level project hierarchy

          Show
          Faruk added a comment - Hi Robert, I think you misunderstood my point, thank you though I would like to use properties instead of strict version numbers in dependencies. defining version numbers as properties and use this properties in dependencies helps management if you have multi level project hierarchy
          Hide
          Robert Scholte added a comment -

          In the original example the <project><version> contains an expression. That can't be right. You can get the same result with my examples.
          When you want to control dependency versions in a multimodule project, you should have a look at dependency management: Define them only in the root project, and remove them from the rest of the project. And AFAIK it is allowed to use expressions here.

          Show
          Robert Scholte added a comment - In the original example the <project><version> contains an expression. That can't be right. You can get the same result with my examples. When you want to control dependency versions in a multimodule project, you should have a look at dependency management: Define them only in the root project, and remove them from the rest of the project. And AFAIK it is allowed to use expressions here.
          Hide
          Scott Carey added a comment - - edited

          child modules can either:

          use
          ${parent.project.version} or ${project.version} to be DRY, if the references are the same as the parent
          not list the version at all and have the parent define it in its dependencyManagement.

          The only thing you can not do is reference a property in the parent/version. All the child modules in your reactor likely have the same version for their parent versions. To manage that, use the versions plugin (NOT release plugin – that this is a mess, conflated design, and buggy in my experience, use 'mvn versions:set' instead).

          There is one situation where the message reported here causes me trouble:

          I have a corporate parent pom, and I want to have its version available via a property to all children. I can create a property 'corporate.root.version' bound to ${project.version}, but that does not work because children re-evaluate it to their own version. Two options seem to work: duplicate the version string in the corporate root – once for its own version declaration and again for this property, and hope nobody forgets to modify one without the other, OR have the version string in a property, and reference it in the project version, which leads to the warning message here.
          Is the value TRULY unstable if the property is defined in this pom, as a constant? I don't believe it is.

          Show
          Scott Carey added a comment - - edited child modules can either: use ${parent.project.version} or ${project.version} to be DRY, if the references are the same as the parent not list the version at all and have the parent define it in its dependencyManagement. The only thing you can not do is reference a property in the parent/version. All the child modules in your reactor likely have the same version for their parent versions. To manage that, use the versions plugin (NOT release plugin – that this is a mess, conflated design, and buggy in my experience, use 'mvn versions:set' instead). There is one situation where the message reported here causes me trouble: I have a corporate parent pom, and I want to have its version available via a property to all children. I can create a property 'corporate.root.version' bound to ${project.version}, but that does not work because children re-evaluate it to their own version. Two options seem to work: duplicate the version string in the corporate root – once for its own version declaration and again for this property, and hope nobody forgets to modify one without the other, OR have the version string in a property, and reference it in the project version, which leads to the warning message here. Is the value TRULY unstable if the property is defined in this pom, as a constant? I don't believe it is.

            People

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

              Dates

              • Created:
                Updated: