Maven
  1. Maven
  2. MNG-2446

parent Pom properties not resolved for module dependencies

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: 2.0.4
    • Fix Version/s: None
    • Component/s: Dependencies
    • Labels:
      None
    • Environment:
      WindowsXP/Linux - JDK 1.4 last version
    • Complexity:
      Intermediate
    • Number of attachments :
      2

      Description

      root-project --> root-pom.xml with <version>$

      {my.version}</version>
      |------->proj1 <parent><version>${my.version}

      </version></parent>

      ------->proj2 <parent><version>$ {my.version}</version></parent>
      | |
      | |->proj1 dependency
      |------->proj3 <parent><version>${my.version}

      </version></parent>

      if I compile from the root-project directory, all compile fine.

      if I compile from the proj2 directory, maven2 resolve proj2-$

      {my.version}
      resolve proj1-${my.version}

      but tries to resolve the parent version root-project-$

      {my.version}

      but this is not resolved.

      1. InstallMojo.quoteReplacement.patch
        0.6 kB
        Henrik Brautaset Aronsen

        Issue Links

          Activity

          Hide
          Hans Dockter added a comment -

          I think this is an major issue.

          We have a complex build where we have poms that declare the modules and other poms that are used for inheritance.

          • api
            • pom.xml (Module declaration)
            • apibasepomDir
              • api-base-pom
            • someprojectDir
              • pom <-- api-base-pom
            • servicesDir
              • pom.xml (Further module declaration)
              • servicesbasepom
                • services-base-pom <-- api-base-pom
              • someServiceDir
                • pom <-- services-base-pom

          We want one and only one definition of the version.

          We do this via properties. In the api-base-pom, which is the parent of every project except the poms declaring the modules, we set a property:

          <properties>
               <krugle.api.version>1.0-SNAPSHOT</krugle.api.version>
           </properties>
          

          This property is available for all projects that inherit from api-base-pom as well as for api-base-pom itself.

          So we can use something like:

          <parent>
                <groupId>x</groupId>
                <artifactId>api-base-pom</artifactId>
                <version>${api.version}</version>
          </parent>
          

          The problem is that the pom declaring the modules don't inherit from the api-base-pom. It would be anyway more intuitive to set the version property in the pom of the api folder, as this is the first one parsed for a build. But if we set the property there, it is only applicable within this pom. So we end up with a situation where we have to define the version property 3 times. We have to separate the pom's declaring the modules from the base-poms used for inheritance, to avoid cyclic references and to trigger certain packaging instructions at the right phase of the build.

          What works is to set the version property via mvn install -D...

          But the version property should be part of the pom, no question about this.

          Basically I want to be able to declare a property that is available for all poms within the module build, regardless of inheritance relationships.

          Show
          Hans Dockter added a comment - I think this is an major issue. We have a complex build where we have poms that declare the modules and other poms that are used for inheritance. api pom.xml (Module declaration) apibasepomDir api-base-pom someprojectDir pom <-- api-base-pom servicesDir pom.xml (Further module declaration) servicesbasepom services-base-pom <-- api-base-pom someServiceDir pom <-- services-base-pom We want one and only one definition of the version. We do this via properties. In the api-base-pom, which is the parent of every project except the poms declaring the modules, we set a property: <properties> <krugle.api.version> 1.0-SNAPSHOT </krugle.api.version> </properties> This property is available for all projects that inherit from api-base-pom as well as for api-base-pom itself. So we can use something like: <parent> <groupId> x </groupId> <artifactId> api-base-pom </artifactId> <version> ${api.version} </version> </parent> The problem is that the pom declaring the modules don't inherit from the api-base-pom. It would be anyway more intuitive to set the version property in the pom of the api folder, as this is the first one parsed for a build. But if we set the property there, it is only applicable within this pom. So we end up with a situation where we have to define the version property 3 times. We have to separate the pom's declaring the modules from the base-poms used for inheritance, to avoid cyclic references and to trigger certain packaging instructions at the right phase of the build. What works is to set the version property via mvn install -D... But the version property should be part of the pom, no question about this. Basically I want to be able to declare a property that is available for all poms within the module build, regardless of inheritance relationships.
          Hide
          Paul Bakker added a comment -

          I agree this is a major issue. We use the exact same mechanism as described by Hans, and run into the same problem.

          Show
          Paul Bakker added a comment - I agree this is a major issue. We use the exact same mechanism as described by Hans, and run into the same problem.
          Hide
          Henrik Brautaset Aronsen added a comment - - edited

          This issue should definately have a major priority. I have the same problem, and I have attached a test case (see maven-version-problem.zip):

          first-+-second---third
                |
                +-fourth
          

          Fourth depends on third. Doing a mvn clean install from root works fine. Doing the same within the fourth module fails to resolve the second artifact:

          [ERROR] BUILD ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] Failed to resolve artifact.
          
          GroupId: me
          ArtifactId: second
          Version: ${applicationVersion}
          

          The problem is in the install plugin. It creates pom files in the repository with an unparsed <version>:

          $ cat ~/.m2/repository/me/second/1.0/second-1.0.pom 
          <?xml version="1.0" encoding="UTF-8"?>
          <project>
              <modelVersion>4.0.0</modelVersion>
          
              <groupId>me</groupId>
              <artifactId>second</artifactId>
              <name>Second</name>
              <packaging>pom</packaging>
              
              <modules>
                <module>third</module>
              </modules>
          
              <parent>
                  <groupId>me</groupId>
                  <artifactId>first</artifactId>
                  <version>${applicationVersion}</version> 
                  <relativePath>../pom.xml</relativePath>
              </parent>
          </project>
          

          If I replace {{$

          {applicationVersion}

          }} with 1.0 in this file, the fourth module builds fine on itself.

          Show
          Henrik Brautaset Aronsen added a comment - - edited This issue should definately have a major priority. I have the same problem, and I have attached a test case (see maven-version-problem.zip ): first-+-second---third | +-fourth Fourth depends on third. Doing a mvn clean install from root works fine. Doing the same within the fourth module fails to resolve the second artifact: [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Failed to resolve artifact. GroupId: me ArtifactId: second Version: ${applicationVersion} The problem is in the install plugin. It creates pom files in the repository with an unparsed <version>: $ cat ~/.m2/repository/me/second/1.0/second-1.0.pom <?xml version= "1.0" encoding= "UTF-8" ?> <project> <modelVersion>4.0.0</modelVersion> <groupId>me</groupId> <artifactId>second</artifactId> <name>Second</name> <packaging>pom</packaging> <modules> <module>third</module> </modules> <parent> <groupId>me</groupId> <artifactId>first</artifactId> <version>${applicationVersion}</version> <relativePath>../pom.xml</relativePath> </parent> </project> If I replace {{$ {applicationVersion} }} with 1.0 in this file, the fourth module builds fine on itself.
          Hide
          Henrik Brautaset Aronsen added a comment -

          I've added a patch against maven-install-plugin in MNG-3057 that fixes this issue. It's sort of a hack, though, I don't reckon the patch will be added to the main stream code.

          Show
          Henrik Brautaset Aronsen added a comment - I've added a patch against maven-install-plugin in MNG-3057 that fixes this issue. It's sort of a hack, though, I don't reckon the patch will be added to the main stream code.
          Hide
          Henrik Brautaset Aronsen added a comment - - edited

          Sorry, I uploaded InstallMojo.quoteReplacement.patch by a mistake. It should have been attached to MNG-3057.

          Show
          Henrik Brautaset Aronsen added a comment - - edited Sorry, I uploaded InstallMojo.quoteReplacement.patch by a mistake. It should have been attached to MNG-3057 .
          Hide
          Brett Porter added a comment -

          I believe this is covered by the linked issues.

          Show
          Brett Porter added a comment - I believe this is covered by the linked issues.
          Hide
          Abhishekh Padmanbhan added a comment - - edited

          I think I might have a workaround/solution to this problem using a profiles.xml (MAVEN 2.1.0) in the root project that holds the project current version as a property. This property then can be used as a value to the version in the parent tag definition in all its sub modules.

          Find below the workaround that I use to propagate the project version variable as a property to all of the project submodule. By doing this I avoid having to redefine the project parent pom version in all its submodules.

          PROJECT STRUCTURE (all caps are modules)

          ROOT

          • pom.xml
          • profiles.xml
          • WAR
            • pom.xml
          • EJB
            • pom.xml

          ROOT/profiles.xml

          <profilesXml>
          <profiles>
              <profile>
                <id>projectProfile</id>
                <activation>
                  <activeByDefault>true</activeByDefault>
                </activation>
                <properties>
                   <currentVersion>1.0.1</currentVersion>
                </properties>
              </profile>
          </profiles>
          </profilesXml>
          

          ROOT/pom.xml

          <project>
            <groupId>projGrp</groupId>
            <artifactId>rootProjName</artifactId>
            <version>${currentVersion}</version>
          </project>
          

          ROOT/EJB/pom.xml

          <project>
            <artifactId>ejbProjName</artifactId>
            <packaging>ejb</packaging>
            <parent>
          	<groupId>projGrp</groupId>
          	<artifactId>rootProjName</artifactId>
          	<version>${currentVersion}</version>
            </parent>
          </project>
          

          I think this way the project version is a property just in one file profiles.xml in the ROOT project and will be the only file that changes when the version changes.

          I have not tested this exhaustively but seems to work in principle.

          Show
          Abhishekh Padmanbhan added a comment - - edited I think I might have a workaround/solution to this problem using a profiles.xml (MAVEN 2.1.0) in the root project that holds the project current version as a property. This property then can be used as a value to the version in the parent tag definition in all its sub modules. Find below the workaround that I use to propagate the project version variable as a property to all of the project submodule. By doing this I avoid having to redefine the project parent pom version in all its submodules. PROJECT STRUCTURE (all caps are modules) ROOT pom.xml profiles.xml WAR pom.xml EJB pom.xml ROOT/profiles.xml <profilesXml> <profiles> <profile> <id>projectProfile</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <currentVersion>1.0.1</currentVersion> </properties> </profile> </profiles> </profilesXml> ROOT/pom.xml <project> <groupId>projGrp</groupId> <artifactId>rootProjName</artifactId> <version>${currentVersion}</version> </project> ROOT/EJB/pom.xml <project> <artifactId>ejbProjName</artifactId> <packaging>ejb</packaging> <parent> <groupId>projGrp</groupId> <artifactId>rootProjName</artifactId> <version>${currentVersion}</version> </parent> </project> I think this way the project version is a property just in one file profiles.xml in the ROOT project and will be the only file that changes when the version changes. I have not tested this exhaustively but seems to work in principle.

            People

            • Assignee:
              Brett Porter
              Reporter:
              Jeremie Poutrin
            • Votes:
              11 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: