Maven
  1. Maven
  2. MNG-2971

Variables are not replaced into installed pom file

    Details

    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      Variables are not replaced into installed pom file.
      Here is a sample pom file
      <project xmlns="http://maven.apache.org/POM/4.0.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

      <modelVersion>4.0.0</modelVersion>
      <groupId>com.xxx.root</groupId>
      <artifactId>root</artifactId>
      <packaging>pom</packaging>
      <version>$

      {prop.version}</version>
      <name>My Project</name>
      ...
      <properties>
      <prop.version>3.0.20</prop.version>
      </properties>

      </project>

      The installed pom is into ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
      is the same as the project pom file but the version referenced into the installed pom file is ${prop.version}

      instead of 3.0.20
      which creates problem to artifacts depending of this one.

      Thanks in advance

      1. pom.xml
        0.4 kB
        Julian Atienza

        Issue Links

          Activity

          Hide
          Stéphane Nicoll added a comment -

          not sure it's related to the install plugin. This sounds like a bad practice to me.

          Show
          Stéphane Nicoll added a comment - not sure it's related to the install plugin. This sounds like a bad practice to me.
          Hide
          Parag Mehta added a comment -

          Yep, seems to be a problem, using properties from settings.xml in version tags or dependencies does not expand the variables and maven creates $

          {var}

          folder in the repository instead of real version.

          Show
          Parag Mehta added a comment - Yep, seems to be a problem, using properties from settings.xml in version tags or dependencies does not expand the variables and maven creates $ {var} folder in the repository instead of real version.
          Hide
          Jörg Hohwiller added a comment -

          I created almost the same issue MNG-3267
          The specific scenario described in MNG-3267 is indeed bad practice but just a workaround for a real problem with maven.
          Anyhow using variables for versions is NOT generally a bad practice!!!
          If you ever managed a really big multiproject with maven (with 3 or more levels and with hundreds of modules)
          you will discover that using explicit versions will drive you crazy, are extremely error prone and maven-release-plugin is no help.

          Show
          Jörg Hohwiller added a comment - I created almost the same issue MNG-3267 The specific scenario described in MNG-3267 is indeed bad practice but just a workaround for a real problem with maven. Anyhow using variables for versions is NOT generally a bad practice!!! If you ever managed a really big multiproject with maven (with 3 or more levels and with hundreds of modules) you will discover that using explicit versions will drive you crazy, are extremely error prone and maven-release-plugin is no help.
          Hide
          Pavel Muller added a comment -

          So, what is a best practice? I've got the same problem. Managing versions in a large multi-module project is really time consuming. I'd like to have just one place to change the version and not to change all poms in my project to modify parent links.

          Show
          Pavel Muller added a comment - So, what is a best practice? I've got the same problem. Managing versions in a large multi-module project is really time consuming. I'd like to have just one place to change the version and not to change all poms in my project to modify parent links.
          Hide
          Marco Lessard added a comment -

          Using maven 2.0.8, we still have the problem with the <parent> tag.

          <parent>
          <groupId>com.mycompany.odp</groupId>
          <artifactId>ocs-core</artifactId>
          <version>$

          {ocs.release.version}

          </version>
          </parent>

          Properties in "project.parent.version" do NOT get substituted but properties in "project.version" do.
          We are on the process of migrating our 900 artifacts project to maven. Most of those artifacts will share the same release version and inherit from the same parent, so it is out of question to do a "search and replace".

          Looks like a substitution bug to me.
          For the moment, it is a show stopper for us that blocks the migration of our 900 artifacts.

          Show
          Marco Lessard added a comment - Using maven 2.0.8, we still have the problem with the <parent> tag. <parent> <groupId>com.mycompany.odp</groupId> <artifactId>ocs-core</artifactId> <version>$ {ocs.release.version} </version> </parent> Properties in "project.parent.version" do NOT get substituted but properties in "project.version" do. We are on the process of migrating our 900 artifacts project to maven. Most of those artifacts will share the same release version and inherit from the same parent, so it is out of question to do a "search and replace". Looks like a substitution bug to me. For the moment, it is a show stopper for us that blocks the migration of our 900 artifacts.
          Hide
          Jörg Hohwiller added a comment -

          similar issue.

          Show
          Jörg Hohwiller added a comment - similar issue.
          Hide
          Ralph Goers added a comment -

          This is a duplicate of MNG-624 - http://jira.codehaus.org/browse/MNG-624. I am working on a fix using that issue.

          Show
          Ralph Goers added a comment - This is a duplicate of MNG-624 - http://jira.codehaus.org/browse/MNG-624 . I am working on a fix using that issue.
          Hide
          Ralph Goers added a comment -

          Reopening since after re-reading it doesn't seem to actually be a duplicate. However, I'm not sure the reported problem will ever be addressed.

          Show
          Ralph Goers added a comment - Reopening since after re-reading it doesn't seem to actually be a duplicate. However, I'm not sure the reported problem will ever be addressed.
          Hide
          Christian Bauer added a comment -

          Until the install plugin is fixed, there is the following workaround:

          You first replace the variables in the pom during the build process by using the assembly plugin
          and install the modified file afterwards over the orginal pom.

          Modified pom:

          <plugin>
          <artifactId>maven-assembly-plugin</artifactId>
          <executions>
          <execution><!-- Replace the placeholder of the pom by their values (used by the install plugin below)-->
          <id>replace-pom-placeholder</id>
          <phase>package</phase>
          <goals><goal>single</goal></goals>
          <configuration>
          <finalName>modified-pom</finalName>
          <descriptors>
          <descriptor>src/assemble/replacePomPlaceholder.xml</descriptor>
          </descriptors>
          </configuration>
          </execution>
          </executions>
          </plugin>

          <plugin>
          <artifactId>maven-install-plugin</artifactId>
          <executions>
          <execution><!-- Replaces the pom (with placeholders) in the repository with the pom without placeholders -->
          <id>overwrite-pom</id>
          <phase>install</phase>
          <goals>
          <goal>install-file</goal>
          </goals>
          <configuration>
          <file>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</file>
          <pomFile>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</pomFile>
          </configuration>
          </execution>
          </executions>
          </plugin>

          Assembly Descriptor replacePomPlaceholder.xml

          <assembly>

          <id>replacePomPlaceholder</id>
          <formats>
          <format>dir</format>
          </formats>

          <files>
          <file>
          <source>pom.xml</source>
          <outputDirectory>/</outputDirectory>
          <filtered>true</filtered>
          </file>
          </files>

          </assembly>

          Show
          Christian Bauer added a comment - Until the install plugin is fixed, there is the following workaround: You first replace the variables in the pom during the build process by using the assembly plugin and install the modified file afterwards over the orginal pom. Modified pom: <plugin> <artifactId>maven-assembly-plugin</artifactId> <executions> <execution><!-- Replace the placeholder of the pom by their values (used by the install plugin below)--> <id>replace-pom-placeholder</id> <phase>package</phase> <goals><goal>single</goal></goals> <configuration> <finalName>modified-pom</finalName> <descriptors> <descriptor>src/assemble/replacePomPlaceholder.xml</descriptor> </descriptors> </configuration> </execution> </executions> </plugin> <plugin> <artifactId>maven-install-plugin</artifactId> <executions> <execution><!-- Replaces the pom (with placeholders) in the repository with the pom without placeholders --> <id>overwrite-pom</id> <phase>install</phase> <goals> <goal>install-file</goal> </goals> <configuration> <file>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</file> <pomFile>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</pomFile> </configuration> </execution> </executions> </plugin> Assembly Descriptor replacePomPlaceholder.xml <assembly> <id>replacePomPlaceholder</id> <formats> <format>dir</format> </formats> <files> <file> <source>pom.xml</source> <outputDirectory>/</outputDirectory> <filtered>true</filtered> </file> </files> </assembly>
          Hide
          John Casey added a comment -

          expressions in <version> elements within the POM are interpolated since Maven 2.1.0. I've actually just introduced some more code to improve that behavior. Is the above problem still present in 2.1.0??

          Show
          John Casey added a comment - expressions in <version> elements within the POM are interpolated since Maven 2.1.0. I've actually just introduced some more code to improve that behavior. Is the above problem still present in 2.1.0??
          Hide
          Jörg Hohwiller added a comment -

          Jep. I just retested this with maven 2.1.0. I still see the variables in the installed pom.
          I also tried the latest released install-plugin.

          Show
          Jörg Hohwiller added a comment - Jep. I just retested this with maven 2.1.0. I still see the variables in the installed pom. I also tried the latest released install-plugin.
          Hide
          Gavin Ellis added a comment -

          For those who want to be able to manage versions dynamically it makes sense for variables to be replaced dynamically in the installed POMs.

          At the very least the installed POMs should be stamped with the variable value at install time. This half way result of having the placeholders still present in the installed POM is of no use to anyone.

          Are there any plans to support either of these features?

          Show
          Gavin Ellis added a comment - For those who want to be able to manage versions dynamically it makes sense for variables to be replaced dynamically in the installed POMs. At the very least the installed POMs should be stamped with the variable value at install time. This half way result of having the placeholders still present in the installed POM is of no use to anyone. Are there any plans to support either of these features?
          Hide
          Jörg Hohwiller added a comment -

          Good point, Gavin. I also voted for this issue, but you are right. It might be a bad idea to let maven figure out what you want by some magic. But if the variable is NOT defined in the POM itself (including inheritance from parent POMs) then it cant be wrong to replace the
          variable because otherwise the installed POM is bad.
          Another way to solve this properly is maybe some command line option to activate this feature. But then you still would not have both ways at a time. An additional tag in <dependency> as trigger, that is stripped when installed, is also a possibility.

          I also opened MNG-4161 so maybe that is a different solution that mainly addresses the same problem if someone cares or wants to vote for.

          Show
          Jörg Hohwiller added a comment - Good point, Gavin. I also voted for this issue, but you are right. It might be a bad idea to let maven figure out what you want by some magic. But if the variable is NOT defined in the POM itself (including inheritance from parent POMs) then it cant be wrong to replace the variable because otherwise the installed POM is bad. Another way to solve this properly is maybe some command line option to activate this feature. But then you still would not have both ways at a time. An additional tag in <dependency> as trigger, that is stripped when installed, is also a possibility. I also opened MNG-4161 so maybe that is a different solution that mainly addresses the same problem if someone cares or wants to vote for.
          Hide
          Jörg Hohwiller added a comment -

          How does this relate to MNG-3057?
          Is this a duplicate? Why was MNG-3057 closed? I am puzzled.
          Can someone bring light into this?

          Show
          Jörg Hohwiller added a comment - How does this relate to MNG-3057 ? Is this a duplicate? Why was MNG-3057 closed? I am puzzled. Can someone bring light into this?
          Hide
          Sheldon Daigle added a comment -

          We have a fairly complex maven environment and without Christian's workaround, we would have been dead in the water. I also agree that installing poms with unexpanded properties is useless.

          Show
          Sheldon Daigle added a comment - We have a fairly complex maven environment and without Christian's workaround, we would have been dead in the water. I also agree that installing poms with unexpanded properties is useless.
          Hide
          Mark Michalek added a comment -

          This is also a problem for us as far as versions are concerned. Would it be feasible to at least replace the versions in installed poms?

          Show
          Mark Michalek added a comment - This is also a problem for us as far as versions are concerned. Would it be feasible to at least replace the versions in installed poms?
          Hide
          yodee added a comment -

          This is a blocker issue for us to migrate from ANT. I voted for this issue to be fixed in the install plugin...

          Show
          yodee added a comment - This is a blocker issue for us to migrate from ANT. I voted for this issue to be fixed in the install plugin...
          Hide
          Jörg Hohwiller added a comment -

          Please also read MNG-624 - this issue is really important for many users.
          Maven has the philosophy "convention over configuration", so in such cases we should avoid ending up with "workaround over usability".

          Show
          Jörg Hohwiller added a comment - Please also read MNG-624 - this issue is really important for many users. Maven has the philosophy "convention over configuration", so in such cases we should avoid ending up with "workaround over usability".
          Hide
          Kannan Kesavan added a comment -

          Hi,

          Do you have any updates on this issue? If it is not going to fix this issue in near future, could you please give the workaround for this at the earliest?

          Thanks and Regards,
          Kannan

          Show
          Kannan Kesavan added a comment - Hi, Do you have any updates on this issue? If it is not going to fix this issue in near future, could you please give the workaround for this at the earliest? Thanks and Regards, Kannan
          Hide
          Luke Lu added a comment -

          IMO, the right fix would be to allow "controlled" property expansion of user defined properties via the maven-install-plugin, a la the latest ant filter <expandproperties regex=".*\.version$"/>, as you definitely do NOT want to expand $

          {java.home}

          or $

          {project.build.directory}

          etc. maven-install-plugin probably should expand anything in <version> elements by default.

          Right now, my workaround is to use maven-antrun-plugin to sanitize the poms before install. The maven-assembly-plugin filter workaround would not work for me as it expands all the properties.

          Show
          Luke Lu added a comment - IMO, the right fix would be to allow "controlled" property expansion of user defined properties via the maven-install-plugin, a la the latest ant filter <expandproperties regex=".*\.version$"/>, as you definitely do NOT want to expand $ {java.home} or $ {project.build.directory} etc. maven-install-plugin probably should expand anything in <version> elements by default. Right now, my workaround is to use maven-antrun-plugin to sanitize the poms before install. The maven-assembly-plugin filter workaround would not work for me as it expands all the properties.
          Hide
          Andreas Pieber added a comment -

          Hey Luke, would you mind sharing the antrun configuration section of your pom with us?

          Show
          Andreas Pieber added a comment - Hey Luke, would you mind sharing the antrun configuration section of your pom with us?
          Hide
          Jorge Agudo Praena added a comment -

          I have this problem in my project. Is there any fix for this issue?

          Show
          Jorge Agudo Praena added a comment - I have this problem in my project. Is there any fix for this issue?
          Hide
          Julian Atienza added a comment - - edited

          That happens to me creating a project from an archetype from my company. Even having the parameters required in the archeype-metadata.xml and passing them on mvn archetype:generate, the resulting pom has not the parameters (groupId, artifactId...) replaced

          This is the output from mvn archetype:generate:

          Using following parameters for creating project from Archetype: mygroup-archetype:1.0-SNAPSHOT
          [INFO] ----------------------------------------------------------------------------
          [INFO] Parameter: groupId, Value: org.myorg.mygroup.myproject
          [INFO] Parameter: artifactId, Value: myproject
          [INFO] Parameter: version, Value: 1.0-SNAPSHOT
          [INFO] Parameter: package, Value: org.myorg.mygroup
          [INFO] Parameter: packageInPathFormat, Value: org/myorg/mygroup
          [INFO] Parameter: version, Value: 1.0-SNAPSHOT
          [INFO] Parameter: package, Value: org.myorg.mygroup
          [INFO] Parameter: groupId, Value: org.myorg.mygroup.myproject
          [INFO] Parameter: artifactId, Value: myproject

          this is the generated project's pom file:

          <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
          <modelVersion>4.0.0</modelVersion>
          <groupId>$org.myorg.mygroup</groupId>
          <artifactId>$mygroup-archetype</artifactId>
          <version>$1.0-SNAPSHOT</version>
          <dependencies>
          <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>3.8.1</version>
          <scope>test</scope>
          </dependency>
          </dependencies>
          </project>

          this is a section of the archetype-metadata.xml for my company's archetype

          <archetype-descriptor
          xmlns="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0 http://maven.apache.org/xsd/archetype-descriptor-1.0.0.xsd"
          name="mygroup-archetype" partial="false">

          <requiredProperties>
          <requiredProperty key="artifactId" />
          <requiredProperty key="groupId" />
          <requiredProperty key="package" />
          </requiredProperties>

          <fileSets>
          <fileSet filtered="true" packaged="true">
          <directory>src/main/java</directory>
          <includes>
          <include>*/.java</include>
          </includes>
          </fileSet>

          <fileSet filtered="true" packaged="true">
          <directory>src/test/java/</directory>
          <includes>
          <include>*/.java</include>
          </includes>
          </fileSet>

          <fileSet filtered="true" packaged="true">
          <directory>/src/main/generated</directory>
          <includes>
          <include>*/.java</include>
          </includes>
          </fileSet>
          ...
          </<archetype-descriptor>

          Show
          Julian Atienza added a comment - - edited That happens to me creating a project from an archetype from my company. Even having the parameters required in the archeype-metadata.xml and passing them on mvn archetype:generate, the resulting pom has not the parameters (groupId, artifactId...) replaced This is the output from mvn archetype:generate: Using following parameters for creating project from Archetype: mygroup-archetype:1.0-SNAPSHOT [INFO] ---------------------------------------------------------------------------- [INFO] Parameter: groupId, Value: org.myorg.mygroup.myproject [INFO] Parameter: artifactId, Value: myproject [INFO] Parameter: version, Value: 1.0-SNAPSHOT [INFO] Parameter: package, Value: org.myorg.mygroup [INFO] Parameter: packageInPathFormat, Value: org/myorg/mygroup [INFO] Parameter: version, Value: 1.0-SNAPSHOT [INFO] Parameter: package, Value: org.myorg.mygroup [INFO] Parameter: groupId, Value: org.myorg.mygroup.myproject [INFO] Parameter: artifactId, Value: myproject this is the generated project's pom file: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd "> <modelVersion>4.0.0</modelVersion> <groupId>$org.myorg.mygroup</groupId> <artifactId>$mygroup-archetype</artifactId> <version>$1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project> this is a section of the archetype-metadata.xml for my company's archetype <archetype-descriptor xmlns="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0 http://maven.apache.org/xsd/archetype-descriptor-1.0.0.xsd " name="mygroup-archetype" partial="false"> <requiredProperties> <requiredProperty key="artifactId" /> <requiredProperty key="groupId" /> <requiredProperty key="package" /> </requiredProperties> <fileSets> <fileSet filtered="true" packaged="true"> <directory>src/main/java</directory> <includes> <include>* / .java</include> </includes> </fileSet> <fileSet filtered="true" packaged="true"> <directory>src/test/java/</directory> <includes> <include>* / .java</include> </includes> </fileSet> <fileSet filtered="true" packaged="true"> <directory>/src/main/generated</directory> <includes> <include>* / .java</include> </includes> </fileSet> ... </<archetype-descriptor>
          Hide
          Seth Call added a comment -

          Since this issue is 6 years old, maybe it's useful to give use-cases as to why one would want to do this.

          This thread discusses why myself and others would like to variablize the version field (summary; to create a scheme where the SCM is the primary source of version info)

          http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tc5543110.html

          Show
          Seth Call added a comment - Since this issue is 6 years old, maybe it's useful to give use-cases as to why one would want to do this. This thread discusses why myself and others would like to variablize the version field (summary; to create a scheme where the SCM is the primary source of version info) http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tc5543110.html
          Hide
          Gustavo Chaves added a comment -

          Hi. I noticed that MNG-4223, which is already related to this issue, seems to be much more researched. Strictly speaking it is a restricted version of this, because it cares only about the artifact coordinate tags with regards to property expansion and not the whole POM. However, since the description of this issue exemplifies the problem with the <version> tag I think that probably the artifact coordinates are all this issue's reporter cares about.

          Is that so?

          If it is, I think it would be a good idea to close this issue marking it as a duplicate of MNG-4223 in order to focus the efforts towards a solution.

          Show
          Gustavo Chaves added a comment - Hi. I noticed that MNG-4223 , which is already related to this issue, seems to be much more researched. Strictly speaking it is a restricted version of this, because it cares only about the artifact coordinate tags with regards to property expansion and not the whole POM. However, since the description of this issue exemplifies the problem with the <version> tag I think that probably the artifact coordinates are all this issue's reporter cares about. Is that so? If it is, I think it would be a good idea to close this issue marking it as a duplicate of MNG-4223 in order to focus the efforts towards a solution.
          Hide
          Shawn Carrillo added a comment - - edited

          @Christian Bauer - Just wanted to say thanks, just what I needed.

          In case others are having the same problems with multi-module projects, I needed to make one small change for ear/war pom configs.
          Under maven-install-plugin configuration, be sure to change <file></file> to the proper ear/war locations respectively.

          ex:
          <configuration>
          <file>target/$

          {project.artifactId}

          -$

          {project.version}

          .war</file>
          <pomFile>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</pomFile>
          </configuration>

          Please also consider this reply a +1 for substitutions in the parent configuration.

          <parent>
          <groupId>com.example</groupId>
          <artifactId>artifact</artifactId>
          <version>$

          {currentVersion}

          </version>
          </parent>

          Show
          Shawn Carrillo added a comment - - edited @Christian Bauer - Just wanted to say thanks, just what I needed. In case others are having the same problems with multi-module projects, I needed to make one small change for ear/war pom configs. Under maven-install-plugin configuration, be sure to change <file></file> to the proper ear/war locations respectively. ex: <configuration> <file>target/$ {project.artifactId} -$ {project.version} .war</file> <pomFile>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</pomFile> </configuration> Please also consider this reply a +1 for substitutions in the parent configuration. <parent> <groupId>com.example</groupId> <artifactId>artifact</artifactId> <version>$ {currentVersion} </version> </parent>
          Hide
          Ravi Luthra added a comment -

          I'm recommending an alternative syntax for "to-be-replaced" variables at install/deploy time. There are now projects that heavily depend on variables now because of the glitch.

          Show
          Ravi Luthra added a comment - I'm recommending an alternative syntax for "to-be-replaced" variables at install/deploy time. There are now projects that heavily depend on variables now because of the glitch.
          Hide
          abhijith nagarajan added a comment -

          Is there any rationale beyond placing the same pom in the repository instead of effective pom?

          Show
          abhijith nagarajan added a comment - Is there any rationale beyond placing the same pom in the repository instead of effective pom?
          Hide
          Mike Gould added a comment -

          We need this for a multi-module build. We want to specify that some sibling module dependencies have the same version as the parent or current project. If we do this:

          <dependency>
          <groupId>com.example</groupId>
          <artifactId>common</artifactId>
          <version>$

          {project.version}

          </version>
          <scope>compile</scope>
          </dependency>

          then the varible appears in the installed pom and then can't be used by anything.

          Currently - like most people - we have a pre-build step which sets all versions accross the whole tree.

          Putting this functionality into the release plugin would be completely useless as the release plugin simply doesn't do the right thing for CI style builds where the version is set from the build number/scm revision etc.

          Show
          Mike Gould added a comment - We need this for a multi-module build. We want to specify that some sibling module dependencies have the same version as the parent or current project. If we do this: <dependency> <groupId>com.example</groupId> <artifactId>common</artifactId> <version>$ {project.version} </version> <scope>compile</scope> </dependency> then the varible appears in the installed pom and then can't be used by anything. Currently - like most people - we have a pre-build step which sets all versions accross the whole tree. Putting this functionality into the release plugin would be completely useless as the release plugin simply doesn't do the right thing for CI style builds where the version is set from the build number/scm revision etc.
          Hide
          Jörg Hohwiller added a comment -

          There is great news for this issue:
          https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin
          Please note that the plugin will move out of sandbox in the future so try mojo instead of sandbox if the link stopped working:
          https://svn.codehaus.org/mojo/trunk/mojo/consumer-maven-plugin

          Simply check-out and install this plugin. Then add this to your toplevel POMs build-section:
          <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>consumer-maven-plugin</artifactId>
          <version>1.0.0-beta-1-SNAPSHOT</version>
          </plugin>

          I hope that the plugin will move out of sandbox and be released soon.

          If you have any feedback please let us know (ideally on MOJOs dev mailing list).

          Show
          Jörg Hohwiller added a comment - There is great news for this issue: https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin Please note that the plugin will move out of sandbox in the future so try mojo instead of sandbox if the link stopped working: https://svn.codehaus.org/mojo/trunk/mojo/consumer-maven-plugin Simply check-out and install this plugin. Then add this to your toplevel POMs build-section: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>consumer-maven-plugin</artifactId> <version>1.0.0-beta-1-SNAPSHOT</version> </plugin> I hope that the plugin will move out of sandbox and be released soon. If you have any feedback please let us know (ideally on MOJOs dev mailing list).
          Hide
          Jörg Hohwiller added a comment -
          Show
          Jörg Hohwiller added a comment - Plugin had to be renamed: http://mojo.codehaus.org/flatten-maven-plugin/
          Hide
          Jörg Hohwiller added a comment -

          2nd release is out in central repo. Just add this to your build section:

          <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>flatten-maven-plugin</artifactId>
          <version>1.0.0-beta-2</version>
          </plugin>

          Show
          Jörg Hohwiller added a comment - 2nd release is out in central repo. Just add this to your build section: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>flatten-maven-plugin</artifactId> <version>1.0.0-beta-2</version> </plugin>

            People

            • Assignee:
              Ralph Goers
              Reporter:
              Laurent Dauvilaire
            • Votes:
              50 Vote for this issue
              Watchers:
              50 Start watching this issue

              Dates

              • Created:
                Updated: