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.3.1
    • 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
          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.
          Hide
          Brandon White added a comment -

          Prior comments on this bug report from Chris Price, Axel Fontaine, Don Brown, Nicolas Grobisa, Cameron Rochester, and Esteban Porcelli describe the same challenges that we experience in our own environment so I won't repeat them here.

          To mitigate the issues we encountered in our own continuous integration-based development landscape, we implemented a solution that is based on Axel Fontaine's suggestions from http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html. There are a number of rough edges with our implementation, particularly for install/deploy, but it has enabled us to centralize our version management in a small number of POMs instead of replicating the version in every POM. Our implementation continues to work with maven versions 3.1.1 up to 3.2.5 but we remain concerned that a subsequent maven release will break some of the admittedly fragile hacks that we have introduced.

          Even if supporting expressions in version fields is the wrong approach according to the core Maven team, it would be really nice if Maven could provide some sort of official solution that allows version metadata to be injected into the POM from outside.

          Part of Nicolas Grobisa's comment from 2012 nails this point well:

          "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
          Brandon White added a comment - Prior comments on this bug report from Chris Price, Axel Fontaine, Don Brown, Nicolas Grobisa, Cameron Rochester, and Esteban Porcelli describe the same challenges that we experience in our own environment so I won't repeat them here. To mitigate the issues we encountered in our own continuous integration-based development landscape, we implemented a solution that is based on Axel Fontaine's suggestions from http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html . There are a number of rough edges with our implementation, particularly for install/deploy, but it has enabled us to centralize our version management in a small number of POMs instead of replicating the version in every POM. Our implementation continues to work with maven versions 3.1.1 up to 3.2.5 but we remain concerned that a subsequent maven release will break some of the admittedly fragile hacks that we have introduced. Even if supporting expressions in version fields is the wrong approach according to the core Maven team, it would be really nice if Maven could provide some sort of official solution that allows version metadata to be injected into the POM from outside. Part of Nicolas Grobisa's comment from 2012 nails this point well: "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."

            People

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

              Dates

              • Created:
                Updated: