Details

    • Number of attachments :
      2

      Description

      (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521)

      currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them.

      One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects.

      This also introduces the need for tool support to populate the version on release and deployment for reproducibility.

        Issue Links

          Activity

          Hide
          Jeff Jensen added a comment -

          On a different use case, with my current understanding, this seems to easily make sense when specifying <relativePath>. In fact, in that case, it seems one could leave off all three: <groupId>, <artifactId>, <version>, since it simply uses the specified one.

          Show
          Jeff Jensen added a comment - On a different use case, with my current understanding, this seems to easily make sense when specifying <relativePath>. In fact, in that case, it seems one could leave off all three: <groupId>, <artifactId>, <version>, since it simply uses the specified one.
          Hide
          Brett Porter added a comment -

          tha'ts not the meaning of <realtivePath> - it still relies on the correct data being used so that the project can be built in isolation. Relative path is a hint for the universal source directory.

          Show
          Brett Porter added a comment - tha'ts not the meaning of <realtivePath> - it still relies on the correct data being used so that the project can be built in isolation. Relative path is a hint for the universal source directory.
          Hide
          brianfox brianfox added a comment -

          here's my 2 cents: What if the parent version could take a tag like LATEST and then the release plugin could resolve it like it does with SNAPSHOTS. IMO, if you can't define your parent in a flexible way, it almost make it pointless to be able to inherit the version from the parent....you still need to go to each pom and update the parent rev. The problem with it always taking the latest is when you tag something, if you go back later the parent could be different.

          Show
          brianfox brianfox added a comment - here's my 2 cents: What if the parent version could take a tag like LATEST and then the release plugin could resolve it like it does with SNAPSHOTS. IMO, if you can't define your parent in a flexible way, it almost make it pointless to be able to inherit the version from the parent....you still need to go to each pom and update the parent rev. The problem with it always taking the latest is when you tag something, if you go back later the parent could be different.
          Hide
          Arik Kfir added a comment -

          two more cents: imo the algoritm should do the following: (in specified order)

          1. if a version is given, resolve it from reactor/repository
          2. otherwise, if a path is given, use that
          3. otherwise, if the project has an SCM, retrieve it from the scm (using same tag/branch/etc)
          4. error

          Show
          Arik Kfir added a comment - two more cents: imo the algoritm should do the following: (in specified order) 1. if a version is given, resolve it from reactor/repository 2. otherwise, if a path is given, use that 3. otherwise, if the project has an SCM, retrieve it from the scm (using same tag/branch/etc) 4. error
          Hide
          Kevin Sheehan added a comment -

          ...and another two cents...

          It appears (from my tests) that the <parent></parent> element is absolutely the first tag accted upon when encountered in the POM. That makes sense HOWEVER... I would like to read / load / substitute variables in that section.

          i.e.
          mvn -Dapp.version=1.0-SNAPSHOT compile

          with POM that contains
          ...
          <parent>
          <artifactId>artifact-id</artifactId>
          <groupId>group-id</groupId>
          <version>$

          {app.version}</version>
          </parent>
          ...

          should be the same as
          ...
          <parent>
          <artifactId>artifact-id</artifactId>
          <groupId>group-id</groupId>
          <version>1.0-SNAPSHOT</version>
          </parent>
          ...

          but is not as the <version>${app.version}

          </version> is LITERALLY substituted rather than recognizing this as an instance of variable substitution.

          Allowing variable substitution in the <parent></parent> section should provide enough flexibility to successfully close this.

          Show
          Kevin Sheehan added a comment - ...and another two cents... It appears (from my tests) that the <parent></parent> element is absolutely the first tag accted upon when encountered in the POM. That makes sense HOWEVER... I would like to read / load / substitute variables in that section. i.e. mvn -Dapp.version=1.0-SNAPSHOT compile with POM that contains ... <parent> <artifactId>artifact-id</artifactId> <groupId>group-id</groupId> <version>$ {app.version}</version> </parent> ... should be the same as ... <parent> <artifactId>artifact-id</artifactId> <groupId>group-id</groupId> <version>1.0-SNAPSHOT</version> </parent> ... but is not as the <version>${app.version} </version> is LITERALLY substituted rather than recognizing this as an instance of variable substitution. Allowing variable substitution in the <parent></parent> section should provide enough flexibility to successfully close this.
          Hide
          Prasad Kashyap added a comment -

          The Geronimo project has about 145 pom.xmls layered in 3 to 4 tiers.

          Ideally, we would like to set the version in one single place and use it repeatedly everywhere. This would include the version for the <project> and for the <parent>. Example :

          <project>
          <parent>
          <groupId>org.apache.geronimo</groupId>
          <artifactId>geronimo-parent</artifactId>
          <version>$

          {geronimoVersion}</version>
          </parent>

          <modelVersion>4.0.0</modelVersion>
          <groupId>org.apache.geronimo.applications</groupId>
          <artifactId>applications-parent</artifactId>
          <version>${geronimoVersion}

          </version>
          ...........

          Such a thing is not possible.

          If we want to do a top level build with 1 single 'mvn' command, then we cannot use $

          {geronimoVersion}

          while declaring the project's and
          parent's version. We will have to explicitly define the version. That would mean changing every single pom.xml every time the release
          changes.

          Setting the version in -D doesn't work either.

          Show
          Prasad Kashyap added a comment - The Geronimo project has about 145 pom.xmls layered in 3 to 4 tiers. Ideally, we would like to set the version in one single place and use it repeatedly everywhere. This would include the version for the <project> and for the <parent>. Example : <project> <parent> <groupId>org.apache.geronimo</groupId> <artifactId>geronimo-parent</artifactId> <version>$ {geronimoVersion}</version> </parent> <modelVersion>4.0.0</modelVersion> <groupId>org.apache.geronimo.applications</groupId> <artifactId>applications-parent</artifactId> <version>${geronimoVersion} </version> ........... Such a thing is not possible. If we want to do a top level build with 1 single 'mvn' command, then we cannot use $ {geronimoVersion} while declaring the project's and parent's version. We will have to explicitly define the version. That would mean changing every single pom.xml every time the release changes. Setting the version in -D doesn't work either.
          Hide
          Brett Porter added a comment -

          you never need a $

          {geronimoVersion}

          property. version is inherited. And you'll have to specify the parent version until this new feature is implemented (you can't get the version of the parent to use from the parent

          You can use the release plugin to automatically update these for you in the mean time.

          Show
          Brett Porter added a comment - you never need a $ {geronimoVersion} property. version is inherited. And you'll have to specify the parent version until this new feature is implemented (you can't get the version of the parent to use from the parent You can use the release plugin to automatically update these for you in the mean time.
          Hide
          Christian Goetze added a comment -

          I would like to add my support for allowing the use of $

          {...}

          in the <parent>...</parent> sections. I just fail to see any downside to it, and it would certainly make my life easier, as I cannot use the release plugin as it is...

          Show
          Christian Goetze added a comment - I would like to add my support for allowing the use of $ {...} in the <parent>...</parent> sections. I just fail to see any downside to it, and it would certainly make my life easier, as I cannot use the release plugin as it is...
          Hide
          Eric Brown added a comment -

          The attached patch and 16 integration tests fixes this issue by allowing the following:

          • Variable expansion works in the <parent> section of pom-s for version, groupId and artifactId
          • The same elements are all optional. At the extreme, this means most times <parent/> will work.

          There is a rule for this to work, however. You must have enough of your development tree on disk that maven can walk the directories (<relativePath> still works) to resolve variables and/or find inferred elements that are missing.

          Implementation Notes:

          • All existing and 16 new integration tests are passing. The code-path and what's going on really doesn't change for existing projects that have explicit <parent> sections.
          • It passes my complex 202-module project.
          • Most of what is going on is that maven now guesses and does re-interpolation later to verify (and/or) continue its inferencing. I call it "expansion" in a few places because it is more than just interpolation, profiles also have to be expanded - but the code was all there, I just refactored slightly.
          • When pom-s are installed and deployed, if any part of their <parent> specification was inferred or re-expanded, it is no longer possible to simply copy the source pom.xml unmodified to the local and/or remote repository. Doing so would make it impossible to build from somewhere other than "trunk" as when building from the middle of a tree, artifacts that are elsewhere in sibling or cousin nodes of the tree are actually fetched from the repository and their parents in-turn from the repository as well. But the parents couldn't be found in the repository because the parent section was missing! So maven now detects that the parent section was missing or needed expansion due to the presence of variables and makes sure the parent section is present before writing a pom to a repository. I'm not fantastically pleased with this implementation for a couple reasons: (though it works and my vote would be to accept it as is - I doubt it is the worst ugliness in the code)
            • The pom in the repository looses all comments and formatting from the original.
            • The way I hooked it into the artifact and suck it back out again when installing and deploying pom-s just felt hackish. Though I really don't see any other way to pass the needed information around as this information obviously was not intended to be passed between the maven-project and maven-artifact modules in the architecture.

          BTW, The reason I spent so much time on this is because I have 202 modules and release twice / month. My svn logs are littered with crap from changing version information in my 202 pom-s and I find it very annoying. Maven is a great tool, but I've never worked with or built a build system where I had to keep version information in so many places. I know there are tools to manage it, but it is still uglier than the patch I've submitted here IMO. YMMV

          Show
          Eric Brown added a comment - The attached patch and 16 integration tests fixes this issue by allowing the following: Variable expansion works in the <parent> section of pom-s for version, groupId and artifactId The same elements are all optional. At the extreme, this means most times <parent/> will work. There is a rule for this to work, however. You must have enough of your development tree on disk that maven can walk the directories (<relativePath> still works) to resolve variables and/or find inferred elements that are missing. Implementation Notes: All existing and 16 new integration tests are passing. The code-path and what's going on really doesn't change for existing projects that have explicit <parent> sections. It passes my complex 202-module project. Most of what is going on is that maven now guesses and does re-interpolation later to verify (and/or) continue its inferencing. I call it "expansion" in a few places because it is more than just interpolation, profiles also have to be expanded - but the code was all there, I just refactored slightly. When pom-s are installed and deployed, if any part of their <parent> specification was inferred or re-expanded, it is no longer possible to simply copy the source pom.xml unmodified to the local and/or remote repository. Doing so would make it impossible to build from somewhere other than "trunk" as when building from the middle of a tree, artifacts that are elsewhere in sibling or cousin nodes of the tree are actually fetched from the repository and their parents in-turn from the repository as well. But the parents couldn't be found in the repository because the parent section was missing! So maven now detects that the parent section was missing or needed expansion due to the presence of variables and makes sure the parent section is present before writing a pom to a repository. I'm not fantastically pleased with this implementation for a couple reasons: (though it works and my vote would be to accept it as is - I doubt it is the worst ugliness in the code) The pom in the repository looses all comments and formatting from the original. The way I hooked it into the artifact and suck it back out again when installing and deploying pom-s just felt hackish. Though I really don't see any other way to pass the needed information around as this information obviously was not intended to be passed between the maven-project and maven-artifact modules in the architecture. BTW, The reason I spent so much time on this is because I have 202 modules and release twice / month. My svn logs are littered with crap from changing version information in my 202 pom-s and I find it very annoying. Maven is a great tool, but I've never worked with or built a build system where I had to keep version information in so many places. I know there are tools to manage it, but it is still uglier than the patch I've submitted here IMO. YMMV
          Hide
          Jason van Zyl added a comment -

          I will take a look but have you run all the integration tests and are certain it doesn't whack anything else. If so then I think we could consider it. I would patch trunk and backport it.

          Show
          Jason van Zyl added a comment - I will take a look but have you run all the integration tests and are certain it doesn't whack anything else. If so then I think we could consider it. I would patch trunk and backport it.
          Hide
          Eric Brown added a comment -

          Yes, all the integration tests run. Both the ones still attached to the maven-2.0.x branch and the ones in core-integration-tests.

          trunk wasn't working for me at the time I started this, so I did it against 2.0.x. I should have dug a bit further I suppose. If you want to open a new issue for this for 2.1, I can look at it when I get a chance, but it'd be great to get this in 2.0.6.

          Show
          Eric Brown added a comment - Yes, all the integration tests run. Both the ones still attached to the maven-2.0.x branch and the ones in core-integration-tests. trunk wasn't working for me at the time I started this, so I did it against 2.0.x. I should have dug a bit further I suppose. If you want to open a new issue for this for 2.1, I can look at it when I get a chance, but it'd be great to get this in 2.0.6.
          Hide
          Brett Porter added a comment -

          I'm certainly interested in taking a look at this. Hoever, I'm not sure if major functionality should be introduced in the .0.x line - esp. if a 2.1 alpha is not far behind.

          Show
          Brett Porter added a comment - I'm certainly interested in taking a look at this. Hoever, I'm not sure if major functionality should be introduced in the .0.x line - esp. if a 2.1 alpha is not far behind.
          Hide
          Jason van Zyl added a comment -

          Unmarking patch, I will take it.

          Show
          Jason van Zyl added a comment - Unmarking patch, I will take it.
          Hide
          Jason van Zyl added a comment -

          This will not make it into the first alpha without some discussion.

          Show
          Jason van Zyl added a comment - This will not make it into the first alpha without some discussion.
          Hide
          Brett Porter added a comment -

          lots of votes - Jason, did you have something in mind for this already based on your last comments?

          Show
          Brett Porter added a comment - lots of votes - Jason, did you have something in mind for this already based on your last comments?
          Hide
          Ian added a comment -

          Allowing variable substitution in the parent section would fix MNG-3070 as well. I've encountered the same problem as Prasad Kashyap with labelling builds on the fly. This also has a side effect that if you have a hierarchical directory structure you can't guarantee to be able to build from an arbitrary sub directory. I think that what is happening is like this - imagine parent project A with sub project B which is dependent on C which is also a child of A.:

          /projectA
          /projectB child of projectA dependent on projectC
          /projectC child of projectA

          If you build from directory B it resolves C as a binary artifact, looks the parent pom of C up in the repository, fails to make the variable substitution and then explodes. This makes it impossible to label builds on the fly AND build from any directory without editing all your pom.xml files.

          Show
          Ian added a comment - Allowing variable substitution in the parent section would fix MNG-3070 as well. I've encountered the same problem as Prasad Kashyap with labelling builds on the fly. This also has a side effect that if you have a hierarchical directory structure you can't guarantee to be able to build from an arbitrary sub directory. I think that what is happening is like this - imagine parent project A with sub project B which is dependent on C which is also a child of A.: /projectA /projectB child of projectA dependent on projectC /projectC child of projectA If you build from directory B it resolves C as a binary artifact, looks the parent pom of C up in the repository, fails to make the variable substitution and then explodes. This makes it impossible to label builds on the fly AND build from any directory without editing all your pom.xml files.
          Hide
          Michael McCallum added a comment -

          Can we please default to forcing a parent version for build reproducibility and just allow variable substitution for people that really really want complicated builds?

          A small but i think very pertinant rant...

          I really feel like the problem is with the way people are setting up there projects and thinking about their pom hierarchies. Pom hierachies should should be functional rather than packaging, where as modules are packaging and not functional.

          Consider it like a java project do you inherit all the way down a package hierarchy?? no because it makes not sense you inherit or implement from super types that give you the specific functionality that you need. e.g. assembly parents, webapp parents, jaxb parents.

          You then group your classes together in packages as they form a component... similar concept with modules projects... they really only need to build similar

          Dependencies should very rarely be in parents if at all you should use standard OO principles to encasulate them in composites that are reused by muliple projects as dependencies.

          I would take a very different approach and completely disallow modules projects from being parents and vice versa.

          We have over 145 artifacts and we release once a week... we don't have dependency changes littered all over the subversion logs... we use ranges and effective versioning processes to keep a consistent build hierarchy... its been a painful road thats really coming together with 2.0.8.

          my 2c

          Show
          Michael McCallum added a comment - Can we please default to forcing a parent version for build reproducibility and just allow variable substitution for people that really really want complicated builds? A small but i think very pertinant rant... I really feel like the problem is with the way people are setting up there projects and thinking about their pom hierarchies. Pom hierachies should should be functional rather than packaging, where as modules are packaging and not functional. Consider it like a java project do you inherit all the way down a package hierarchy?? no because it makes not sense you inherit or implement from super types that give you the specific functionality that you need. e.g. assembly parents, webapp parents, jaxb parents. You then group your classes together in packages as they form a component... similar concept with modules projects... they really only need to build similar Dependencies should very rarely be in parents if at all you should use standard OO principles to encasulate them in composites that are reused by muliple projects as dependencies. I would take a very different approach and completely disallow modules projects from being parents and vice versa. We have over 145 artifacts and we release once a week... we don't have dependency changes littered all over the subversion logs... we use ranges and effective versioning processes to keep a consistent build hierarchy... its been a painful road thats really coming together with 2.0.8. my 2c
          Hide
          Ian added a comment -

          Having done all of that, I still think it would be good to be able to dynamically label all the build artifacts with the same version, including the top-level pom.

          Show
          Ian added a comment - Having done all of that, I still think it would be good to be able to dynamically label all the build artifacts with the same version, including the top-level pom.
          Hide
          Jean-Charles Meyrignac added a comment -

          I was building Selenium, and found that I could propagate automatically the version number as follows:
          <parent>
          <groupId>org.openqa.selenium</groupId>
          <version>$

          {SeleniumVersion}

          </version>
          <artifactId>selenium-rc</artifactId>
          </parent>

          This worked on Maven 2.0.4, but doesn't with 2.0.6.
          Alas, I was forced to upgrade due to maven-assembly-plugin, version 2.2-beta-2-SNAPSHOT, which forces the use of 2.0.6.

          Show
          Jean-Charles Meyrignac added a comment - I was building Selenium, and found that I could propagate automatically the version number as follows: <parent> <groupId>org.openqa.selenium</groupId> <version>$ {SeleniumVersion} </version> <artifactId>selenium-rc</artifactId> </parent> This worked on Maven 2.0.4, but doesn't with 2.0.6. Alas, I was forced to upgrade due to maven-assembly-plugin, version 2.2-beta-2-SNAPSHOT, which forces the use of 2.0.6.
          Hide
          Jörg Hohwiller added a comment -

          Same idea was suggested in MNG-3267

          Show
          Jörg Hohwiller added a comment - Same idea was suggested in MNG-3267
          Hide
          Henrik Brautaset Aronsen added a comment - - edited

          MNG-3057 also has a small patch on maven-install-plugin that fixes the property substitution in <parent>. There's a test case for it in MNG-2446.

          Show
          Henrik Brautaset Aronsen added a comment - - edited MNG-3057 also has a small patch on maven-install-plugin that fixes the property substitution in <parent>. There's a test case for it in MNG-2446 .
          Hide
          Henrik Brautaset Aronsen added a comment -

          MINSTALL-50 also has a patch for this issue.

          Show
          Henrik Brautaset Aronsen added a comment - MINSTALL-50 also has a patch for this issue.
          Hide
          Harsha Rai added a comment -

          Hello:

          I filed the following:
          http://jira.codehaus.org/browse/MARTIFACT-32

          The issue is almost the same. I didn't know which maven component the issue belonged to? Is there a workaround for this?

          thanks..

          Show
          Harsha Rai added a comment - Hello: I filed the following: http://jira.codehaus.org/browse/MARTIFACT-32 The issue is almost the same. I didn't know which maven component the issue belonged to? Is there a workaround for this? thanks..
          Hide
          Henrik Brautaset Aronsen added a comment -

          Harsha: There is a simple patch in MNG-3057 which solves this issue.

          Show
          Henrik Brautaset Aronsen added a comment - Harsha: There is a simple patch in MNG-3057 which solves this issue.
          Hide
          Harsha Rai added a comment - - edited

          Hello:
          Could someone provide a pointer to the process where one can patch and get a release of maven install plugin and manve-project.

          I've a simple patch to the problem mentioned in this issue (MNG-624) and MNG-3057.

          Also, what is the timeline for the fix proposed here (by Ralph Goers) is getting into the next release of maven.

          Greatly appreciate your comments and direction in this regard.

          Thanks..
          Harsha

          Show
          Harsha Rai added a comment - - edited Hello: Could someone provide a pointer to the process where one can patch and get a release of maven install plugin and manve-project. I've a simple patch to the problem mentioned in this issue ( MNG-624 ) and MNG-3057 . Also, what is the timeline for the fix proposed here (by Ralph Goers) is getting into the next release of maven. Greatly appreciate your comments and direction in this regard. Thanks.. Harsha
          Hide
          Ralph Goers added a comment -

          I've committed a fix for MNG-624 onto branch maven-2.1.x-MNG-624 so you all can test it. Here's what I've done:

          I'm only trying to resolve the parent version. I could try to resolve the parent groupId and artifactId but I just couldn't think of a reason why they wouldn't be specified.

          The version is obtained by
          1. Resolving any variables provided via system properties (variables from parents won't be found since the parent isn't known.
          2. Looking in the file cache for the resolved parent project using the relative location as the key.
          3. Looking for the parent at the relative path on disk.
          a. The target directory at the relative path is inspected for a modified pom.
          b. The project at the relative path is used.
          If at the end of this a resolved parent version is not located throw an Exception. Do not try to recurse to further parents.

          You'll notice the comment about looking for the modified pom in the target directory. As part of this fix the parent version, and the project's artifactId, groupId and version are all interpolated. If any of those fields were missing or had variables in them in the original pom then the pom is modified and written to the target directory. Thus, any pom that is installed or deployed will always have these fields resolved.

          In looking through the plugins it looked to me that the Eclipse and Invoker plugins are trying to locate the base directory by calling project.getFile().getParentFile(). These will need to be changed to project.getBasedir() since the location of the pom might now be in a different place and project.getFile().getParentFile() might return the target directory instead of the base directory.

          Maven 2.1 will require Java 5.

          Please test and provide feedback.

          Show
          Ralph Goers added a comment - I've committed a fix for MNG-624 onto branch maven-2.1.x- MNG-624 so you all can test it. Here's what I've done: I'm only trying to resolve the parent version. I could try to resolve the parent groupId and artifactId but I just couldn't think of a reason why they wouldn't be specified. The version is obtained by 1. Resolving any variables provided via system properties (variables from parents won't be found since the parent isn't known. 2. Looking in the file cache for the resolved parent project using the relative location as the key. 3. Looking for the parent at the relative path on disk. a. The target directory at the relative path is inspected for a modified pom. b. The project at the relative path is used. If at the end of this a resolved parent version is not located throw an Exception. Do not try to recurse to further parents. You'll notice the comment about looking for the modified pom in the target directory. As part of this fix the parent version, and the project's artifactId, groupId and version are all interpolated. If any of those fields were missing or had variables in them in the original pom then the pom is modified and written to the target directory. Thus, any pom that is installed or deployed will always have these fields resolved. In looking through the plugins it looked to me that the Eclipse and Invoker plugins are trying to locate the base directory by calling project.getFile().getParentFile(). These will need to be changed to project.getBasedir() since the location of the pom might now be in a different place and project.getFile().getParentFile() might return the target directory instead of the base directory. Maven 2.1 will require Java 5. Please test and provide feedback.
          Hide
          Jason van Zyl added a comment -

          Ralph, is there some example projects in the branch somewhere? I just want to see what you see as the layout.

          I see it as a set of projects on disk, that are all connected, chaining upward to the parent where it has the implicit Super POM parent, or is not connected to its parent on disk. If this is the case then the version element in parent references wouldn't even be required as all the projects are connected. Once you have that contained set then the one version is either specified explicitly or as a property. I always assumed in this case it's all or nothing in that people wouldn't be checking out leaf node projects and trying to build them.

          Show
          Jason van Zyl added a comment - Ralph, is there some example projects in the branch somewhere? I just want to see what you see as the layout. I see it as a set of projects on disk, that are all connected, chaining upward to the parent where it has the implicit Super POM parent, or is not connected to its parent on disk. If this is the case then the version element in parent references wouldn't even be required as all the projects are connected. Once you have that contained set then the one version is either specified explicitly or as a property. I always assumed in this case it's all or nothing in that people wouldn't be checking out leaf node projects and trying to build them.
          Hide
          Harsha Rai added a comment -

          Hi: Ralph

          May be I'm missing something on:
          quote:
          1. Resolving any variables provided via system properties (variables from parents won't be found since the parent isn't known.

          So, what I understand is, the variables in the parent are still not getting expanded.?
          If so, I would like to make the following suggestion. We don't have to evaluate variable in parent at the time... Today, when I give
          a variable in parent, mvn gets stuck at searching for $

          {parent} in the repo. in the default project builder. Isn't that simple enough to replace the ${parent}

          with system property , or project.properties. Once a valid value is found in either of these, one can update the project model with right parent info. Isn't it?

          I will try 2.1 and let you know.

          thanks..

          Show
          Harsha Rai added a comment - Hi: Ralph May be I'm missing something on: quote: 1. Resolving any variables provided via system properties (variables from parents won't be found since the parent isn't known. So, what I understand is, the variables in the parent are still not getting expanded.? If so, I would like to make the following suggestion. We don't have to evaluate variable in parent at the time... Today, when I give a variable in parent, mvn gets stuck at searching for $ {parent} in the repo. in the default project builder. Isn't that simple enough to replace the ${parent} with system property , or project.properties. Once a valid value is found in either of these, one can update the project model with right parent info. Isn't it? I will try 2.1 and let you know. thanks..
          Hide
          Ralph Goers added a comment - - edited

          If you are doing a multiproject build the projects will be cached internally by their full path. As the various projects are built they will find the fully resolved projects in the cache. Then, as the projects are processed their pom.xml files will be modified so that there are no variables for the artifactId, groupId and version and they will be placed into their respective target directories. If you then do a build from a subproject it will find the pom in the parent's target directory. Since the variables have been replaced there is no need to recurse.

          What the comment about the variables not being known means is that before looking for the parent an attempt is made to resolve the version. If they variable for the version is defined in the current pom or a system property it will be resolved. Since the parent hasn't been located yet the variable can't be resolved from there. If the version is resolved by doing this no attempt is even made to look for the parent project. If it isn't then the other steps are followed.

          Show
          Ralph Goers added a comment - - edited If you are doing a multiproject build the projects will be cached internally by their full path. As the various projects are built they will find the fully resolved projects in the cache. Then, as the projects are processed their pom.xml files will be modified so that there are no variables for the artifactId, groupId and version and they will be placed into their respective target directories. If you then do a build from a subproject it will find the pom in the parent's target directory. Since the variables have been replaced there is no need to recurse. What the comment about the variables not being known means is that before looking for the parent an attempt is made to resolve the version. If they variable for the version is defined in the current pom or a system property it will be resolved. Since the parent hasn't been located yet the variable can't be resolved from there. If the version is resolved by doing this no attempt is even made to look for the parent project. If it isn't then the other steps are followed.
          Hide
          Ralph Goers added a comment - - edited

          Ralph, is there some example projects in the branch somewhere? I just want to see what you see as the layout.

          I haven't checked in the tests yet. I can attach a few sample projects here. Most were somewhat based on some of the tests that are already attached to the issue, although my patch doesn't support an empty parent element.


          I see it as a set of projects on disk, that are all connected, chaining upward to the parent where it has the implicit Super POM parent, or is not connected to its parent on disk. If this is the case then the version element in parent references wouldn't even be required as all the projects are connected. Once you have that contained set then the one version is either specified explicitly or as a property. I always assumed in this case it's all or nothing in that people wouldn't be checking out leaf node projects and trying to build them.

          The parent element does not require the version element to be specified. If it is specified it can contain a variable. The only real advantage to using a variable is if you check out a subproject in theory you could build that project in isolation by defining the variable with a -D.

          Show
          Ralph Goers added a comment - - edited Ralph, is there some example projects in the branch somewhere? I just want to see what you see as the layout. I haven't checked in the tests yet. I can attach a few sample projects here. Most were somewhat based on some of the tests that are already attached to the issue, although my patch doesn't support an empty parent element. I see it as a set of projects on disk, that are all connected, chaining upward to the parent where it has the implicit Super POM parent, or is not connected to its parent on disk. If this is the case then the version element in parent references wouldn't even be required as all the projects are connected. Once you have that contained set then the one version is either specified explicitly or as a property. I always assumed in this case it's all or nothing in that people wouldn't be checking out leaf node projects and trying to build them. The parent element does not require the version element to be specified. If it is specified it can contain a variable. The only real advantage to using a variable is if you check out a subproject in theory you could build that project in isolation by defining the variable with a -D.
          Hide
          Dan Fabulich added a comment -

          I agree, I think I need to see integration tests that act as examples.

          Show
          Dan Fabulich added a comment - I agree, I think I need to see integration tests that act as examples.
          Hide
          Eric Brown added a comment -

          I recognize that the patch I submitted is now out of date - it was against 2.0. And it has 16 integration tests! I was assured both here and on the mailing list that if there were sufficient integration tests, the patch would be taken, but it never has been.

          This was (still is?) the most watched & voted maven issue in jira.

          Honestly, I've lost interest in maven, but I thought I'd point out what might have been missed in all the comments since I submitted a patch to fix this issue.

          Show
          Eric Brown added a comment - I recognize that the patch I submitted is now out of date - it was against 2.0. And it has 16 integration tests! I was assured both here and on the mailing list that if there were sufficient integration tests, the patch would be taken, but it never has been. This was (still is?) the most watched & voted maven issue in jira. Honestly, I've lost interest in maven, but I thought I'd point out what might have been missed in all the comments since I submitted a patch to fix this issue.
          Hide
          Ralph Goers added a comment -

          I recognize that the patch I submitted is now out of date - it was against 2.0. And it has 16 integration tests! I was assured both here and on the mailing list that if there were sufficient integration tests, the patch would be taken, but it never has been.

          I looked at your patch and your tests. The tests were a big help but there were certain things I just didn't like about the patch - which you actually mentioned. I really didn't like the way it hooked into the artifact - the way I'm doing it doesn't require that. I also didn't like what the modified pom file looked like. With this version it is patching the original XML file, not generating an entirely new one. But be assured that I had your patch file open on my screen the whole time to see how you had done it.

          Show
          Ralph Goers added a comment - I recognize that the patch I submitted is now out of date - it was against 2.0. And it has 16 integration tests! I was assured both here and on the mailing list that if there were sufficient integration tests, the patch would be taken, but it never has been. I looked at your patch and your tests. The tests were a big help but there were certain things I just didn't like about the patch - which you actually mentioned. I really didn't like the way it hooked into the artifact - the way I'm doing it doesn't require that. I also didn't like what the modified pom file looked like. With this version it is patching the original XML file, not generating an entirely new one. But be assured that I had your patch file open on my screen the whole time to see how you had done it.
          Hide
          Eric Brown added a comment -

          Hi Ralph, Thanks for the feedback. I'm glad it was looked at and progress is being made. And it would be great if it could be done cleaner than I did it.

          Being the most watched and voted on issue in jira, I'd encourage the maven team to find a solution sooner than later even if it means a less than perfectly elegant solution.

          Show
          Eric Brown added a comment - Hi Ralph, Thanks for the feedback. I'm glad it was looked at and progress is being made. And it would be great if it could be done cleaner than I did it. Being the most watched and voted on issue in jira, I'd encourage the maven team to find a solution sooner than later even if it means a less than perfectly elegant solution.
          Hide
          Ralph Goers added a comment - - edited

          I've committed some maven projects to https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/resources/mng-0624/. noParentInTree and parentBadPath will both fail. The others should build fine. I have not checked in any of the Java ITs to run these yet.

          Show
          Ralph Goers added a comment - - edited I've committed some maven projects to https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/resources/mng-0624/ . noParentInTree and parentBadPath will both fail. The others should build fine. I have not checked in any of the Java ITs to run these yet.
          Hide
          Ralph Goers added a comment -

          These are notes for myself. I've been working with Brian and found two issues. First, if you are trying to build a grandchild the child project must have been processed (put into the target directory). Second, the patch is not using the outputdir attribute to locate the target directory. Unfortunately, the only solution to determine the "real" value of the attribute is to interpolate the parents to see if they have set the value. Since this means walking up the parent tree it will mean a bit of rework.

          Show
          Ralph Goers added a comment - These are notes for myself. I've been working with Brian and found two issues. First, if you are trying to build a grandchild the child project must have been processed (put into the target directory). Second, the patch is not using the outputdir attribute to locate the target directory. Unfortunately, the only solution to determine the "real" value of the attribute is to interpolate the parents to see if they have set the value. Since this means walking up the parent tree it will mean a bit of rework.
          Hide
          John Casey added a comment -

          Moving this to the 2.x bucket, until we're ready to put it into a particular release.

          Show
          John Casey added a comment - Moving this to the 2.x bucket, until we're ready to put it into a particular release.
          Hide
          Anders Kr. Andersen added a comment -

          A solution could be just to accept this version fact in maven

          And then add a command to update siblings with a trunk version number.

          I sit with a large project where we have the same issue with <url>.
          We want to make a site for each version == for each maven coordinate.

          Here I have decided that trunk is called URL=http://my.site.server/sites/..../trunk
          And the coresponding tagged versions is called URL=http://my.site.server/sites/..../tags/artifactId-vvvv

          To deal with this I am going to make a pom-maintain-maven-plugin
          And have this plugin being able to maintain, SITE-URL, parent version, repository URL,

          For a long time I was experimenting with expression-language. $

          {project.version}

          or $

          {my-url-path}

          etc
          I ended up dropping the expression language solution

          Because I actually also want to force some naming standard into the artifacts.
          Many fields can be calculated by the projects location in the VCS etc.
          I am thinking about some groovy stuff to express rules.

          Show
          Anders Kr. Andersen added a comment - A solution could be just to accept this version fact in maven And then add a command to update siblings with a trunk version number. I sit with a large project where we have the same issue with <url>. We want to make a site for each version == for each maven coordinate. Here I have decided that trunk is called URL= http://my.site.server/sites/..../trunk And the coresponding tagged versions is called URL= http://my.site.server/sites/..../tags/artifactId-vvvv To deal with this I am going to make a pom-maintain-maven-plugin And have this plugin being able to maintain, SITE-URL, parent version, repository URL, For a long time I was experimenting with expression-language. $ {project.version} or $ {my-url-path} etc I ended up dropping the expression language solution Because I actually also want to force some naming standard into the artifacts. Many fields can be calculated by the projects location in the VCS etc. I am thinking about some groovy stuff to express rules.
          Hide
          Oleksandr Maksymchuk added a comment -

          Anders will you make public pom-maintain-maven-plugin?
          I'm greatly interested in it too.

          Show
          Oleksandr Maksymchuk added a comment - Anders will you make public pom-maintain-maven-plugin? I'm greatly interested in it too.
          Hide
          Stephen Connolly added a comment -

          mvn -N versions:set -DnewVersion=____

          or mvn versions:update-parent

          or mvn -N versions:update-child-modules

          can all help updating the parent versions

          Show
          Stephen Connolly added a comment - mvn -N versions:set -DnewVersion=____ or mvn versions:update-parent or mvn -N versions:update-child-modules can all help updating the parent versions
          Hide
          Hans-Peter Störr added a comment -

          The problem is not so much that updating the poms is difficult, but rather that changing the poms has some quite annoying consequences. So I wish to strongly support the plea to remove the unnecessary requirement to put the parent version number into all poms.

          This restriction can make quite some trouble with version control systems. At least it did in our projects. The reason of the trouble is that you need to check in a new version of the pom each time the version number changes - even if absolutely nothing changes about the way to build the system. Over time you have loads of versions checked in and it is hard to tell when there were actual changes in the pom, or just a checkin because of a version number change. When merging releases you have trouble, since there are loads of pom changes all over the place but it is hard to tell where something actually changed. In our particular setting this is even more annoying than this sounds, but this is a long story.

          How would you feel if a strange compiler required you to put the current version number into each and every file? Maven actually does this - after all a pom is a kind source code describing the way to build the system. 8-/
          It is up to you if you want to do this for some reason, but it is not good to force everyone to do it.

          Show
          Hans-Peter Störr added a comment - The problem is not so much that updating the poms is difficult, but rather that changing the poms has some quite annoying consequences. So I wish to strongly support the plea to remove the unnecessary requirement to put the parent version number into all poms. This restriction can make quite some trouble with version control systems. At least it did in our projects. The reason of the trouble is that you need to check in a new version of the pom each time the version number changes - even if absolutely nothing changes about the way to build the system. Over time you have loads of versions checked in and it is hard to tell when there were actual changes in the pom, or just a checkin because of a version number change. When merging releases you have trouble, since there are loads of pom changes all over the place but it is hard to tell where something actually changed. In our particular setting this is even more annoying than this sounds, but this is a long story. How would you feel if a strange compiler required you to put the current version number into each and every file? Maven actually does this - after all a pom is a kind source code describing the way to build the system. 8-/ It is up to you if you want to do this for some reason, but it is not good to force everyone to do it.
          Hide
          brianfox brianfox added a comment -

          Hans, The best approach in this case is really to try and minimize the churn in your parent poms. For a single multi-module build, these would be snapshot references until release time, when the release plugin would update them all. It's a problem when you inherit from a parent that is external to the given multi-module build, and those ones hopefully don't change often. Even in the maven project since 2.x we've only changed ~13 times.

          Show
          brianfox brianfox added a comment - Hans, The best approach in this case is really to try and minimize the churn in your parent poms. For a single multi-module build, these would be snapshot references until release time, when the release plugin would update them all. It's a problem when you inherit from a parent that is external to the given multi-module build, and those ones hopefully don't change often. Even in the maven project since 2.x we've only changed ~13 times.
          Hide
          Hans-Peter Störr added a comment - - edited

          Brian: We also have had about a dozen parent pom changes so far, but this is still an annoying problem. (It might also be much worse if you do an agile project, turning out bi-weekly releases for years.)
          The parent is actually intern to our multi module build. Perhaps a small example:

          project/pom.xml - aggregator for the parent, module1, module2
          project/parent/pom.xml - contains dependencyManagement etc.
          project/module1/pom.xml
          project/module2/pom.xml

          If you switch the version number, you should need to change only one pom.xml. Right now you have to change all 4, or in our case, all 300.

          As I said: the problem is not the work of changing the poms - this is easily done by script - but some annoying consequences of this unnecessary change. These might in part be because of our particular set-up, but the number of votes and watchers shows we are not the only ones who feel the pain. So why not allow to omit the version numbers at all if the parent of a sub-module can be accessed by relative path? No harm is done for those who want to do it otherwise.

          Show
          Hans-Peter Störr added a comment - - edited Brian: We also have had about a dozen parent pom changes so far, but this is still an annoying problem. (It might also be much worse if you do an agile project, turning out bi-weekly releases for years.) The parent is actually intern to our multi module build. Perhaps a small example: project/pom.xml - aggregator for the parent, module1, module2 project/parent/pom.xml - contains dependencyManagement etc. project/module1/pom.xml project/module2/pom.xml If you switch the version number, you should need to change only one pom.xml. Right now you have to change all 4, or in our case, all 300. As I said: the problem is not the work of changing the poms - this is easily done by script - but some annoying consequences of this unnecessary change. These might in part be because of our particular set-up, but the number of votes and watchers shows we are not the only ones who feel the pain. So why not allow to omit the version numbers at all if the parent of a sub-module can be accessed by relative path? No harm is done for those who want to do it otherwise.
          Hide
          Robert Simmons Jr. added a comment -

          I would like to reiterate others points on this issue. Personally I think <relativePath> should be enough to specify a parent POM. I see many maven developers proselytizing about how projects should be created and how POMs should be maintained but the fact is that in an organization changing the entire process to suit Maven is not possible. The second fact is that one size or process doesnt fit all with projects.

          I can think of a dozen examples where projects must stay in locked version with their parent. For example, a project consisting of a data layer, web layer, web service interface and EJBs will all form one cohesive release as a war. They must stay together in versions but they shouldn't have to be updating all 6 files (projects and parent pom) each time there is a version change. They should be able to state a single version number in a parent and use that.

          The thinking behind different versions for each project and super pom being separate is only one use case. That use case assumes all projects are more or less independent builds. This isnt the case with other projects.

          Using <relativePath> to specify "take version from the parent pom" is the best of both worlds as it allows both models and takes nothing away from anyone. That seems to be a much more practical way to go then shouting from the rooftops "NO YOU ARE DOING IT ALL WRONG, THROW OUT YOUR MILLIONS IN INVESTMENT AND REARCHITECT YOUR PROJECT OUR WAY." By shouting that, you are simply telling my boss "nah we will stick with ant" and that is counterproductive.

          Show
          Robert Simmons Jr. added a comment - I would like to reiterate others points on this issue. Personally I think <relativePath> should be enough to specify a parent POM. I see many maven developers proselytizing about how projects should be created and how POMs should be maintained but the fact is that in an organization changing the entire process to suit Maven is not possible. The second fact is that one size or process doesnt fit all with projects. I can think of a dozen examples where projects must stay in locked version with their parent. For example, a project consisting of a data layer, web layer, web service interface and EJBs will all form one cohesive release as a war. They must stay together in versions but they shouldn't have to be updating all 6 files (projects and parent pom) each time there is a version change. They should be able to state a single version number in a parent and use that. The thinking behind different versions for each project and super pom being separate is only one use case. That use case assumes all projects are more or less independent builds. This isnt the case with other projects. Using <relativePath> to specify "take version from the parent pom" is the best of both worlds as it allows both models and takes nothing away from anyone. That seems to be a much more practical way to go then shouting from the rooftops "NO YOU ARE DOING IT ALL WRONG, THROW OUT YOUR MILLIONS IN INVESTMENT AND REARCHITECT YOUR PROJECT OUR WAY." By shouting that, you are simply telling my boss "nah we will stick with ant" and that is counterproductive.
          Hide
          brianfox brianfox added a comment -

          No one is disagreeing that this wouldn't be useful. The fact is we have Maven 2 right now and in my experience, it turns out not to be a huge problem in a "maven normalized" project. Therefore, some guidance can be given how to minimize the impact. If that's "proselytizing", so be it.

          Anyway, we ARE working on this, but it's not as simple as it appears at first glance. The poms must be interpolated before they are deployed to a repository. This is contingent upon knowing exactly where on disk to find the parent pom. The relativePath currently only points to the root of the parent project. Since that parent project also needed to be interpolated, we need to discover the interpolated version of it in that folder. Most of the time this would be /target but not if someone used the build.outputDirectory to change to something else. Finding this location in a manner that respects people's ability to customize their layout from "maven normal" and at the same time being FAST is not easy to do in M2.

          Show
          brianfox brianfox added a comment - No one is disagreeing that this wouldn't be useful. The fact is we have Maven 2 right now and in my experience, it turns out not to be a huge problem in a "maven normalized" project. Therefore, some guidance can be given how to minimize the impact. If that's "proselytizing", so be it. Anyway, we ARE working on this, but it's not as simple as it appears at first glance. The poms must be interpolated before they are deployed to a repository. This is contingent upon knowing exactly where on disk to find the parent pom. The relativePath currently only points to the root of the parent project. Since that parent project also needed to be interpolated, we need to discover the interpolated version of it in that folder. Most of the time this would be /target but not if someone used the build.outputDirectory to change to something else. Finding this location in a manner that respects people's ability to customize their layout from "maven normal" and at the same time being FAST is not easy to do in M2.
          Hide
          Paul Benedict added a comment -

          I've seen POMs deployed with <relativePath> in usage. Is it a good idea to continue supporting that since it's no longer "on disk"?

          Show
          Paul Benedict added a comment - I've seen POMs deployed with <relativePath> in usage. Is it a good idea to continue supporting that since it's no longer "on disk"?
          Hide
          Brett Porter added a comment -

          giving this a more concrete target. If we can get it done sooner, great

          Show
          Brett Porter added a comment - giving this a more concrete target. If we can get it done sooner, great
          Hide
          Abhishekh Padmanbhan added a comment -

          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 - 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.
          Hide
          Pavel Savara added a comment -

          We have this on Robocode project. where it works fine. But if you develop some library (jni4net in my case) all the artifacts uploaded to maven repository will have <version>$

          {currentVersion}

          </version>. And that will not work for users of your library.

          Show
          Pavel Savara added a comment - We have this on Robocode project. where it works fine. But if you develop some library (jni4net in my case) all the artifacts uploaded to maven repository will have <version>$ {currentVersion} </version>. And that will not work for users of your library.
          Hide
          Abhishekh Padmanbhan added a comment - - edited

          Yes you are correct this breaks the transitive dependency resolution when these POM's are used as dependencies in other projects. We almost always do not benefit from the transitive dependencies on our internal projects anyway. Any such tightly coupled modules are placed usually as sub modules which I guess would be atypical with open source development scenario.

          Show
          Abhishekh Padmanbhan added a comment - - edited Yes you are correct this breaks the transitive dependency resolution when these POM's are used as dependencies in other projects. We almost always do not benefit from the transitive dependencies on our internal projects anyway. Any such tightly coupled modules are placed usually as sub modules which I guess would be atypical with open source development scenario.
          Hide
          Abhishekh Padmanbhan added a comment - - edited

          I guess for now use the mvn versions:set goal of the maven 2 versions plugin to set the appropriate version reference in the parent pom and all its child modules.

          Show
          Abhishekh Padmanbhan added a comment - - edited I guess for now use the mvn versions:set goal of the maven 2 versions plugin to set the appropriate version reference in the parent pom and all its child modules.
          Hide
          LEONID ILYEVSKY added a comment - - edited

          Thanks Abhishekh, this looks like an interesting workaround.

          To solve the issue of undefined $

          {currentVersion}

          variable in the deployed pom I am trying to put the profile description right there in pom.xml of the parent project, not in the separate profiles.xml file. Then it is deployed to the repository. However, it does not actually solve anything.
          I guess, as the last resort, I will have to use the "versions" plugin.

          On the other note, I agree with Robert that "<relativePath> should be enough to specify a parent POM.". Maybe we will see this fixed in the near future.

          Show
          LEONID ILYEVSKY added a comment - - edited Thanks Abhishekh, this looks like an interesting workaround. To solve the issue of undefined $ {currentVersion} variable in the deployed pom I am trying to put the profile description right there in pom.xml of the parent project, not in the separate profiles.xml file. Then it is deployed to the repository. However, it does not actually solve anything. I guess, as the last resort, I will have to use the "versions" plugin. On the other note, I agree with Robert that "<relativePath> should be enough to specify a parent POM.". Maybe we will see this fixed in the near future.
          Hide
          Jörg Hohwiller added a comment -

          Thanks to Abhishekh Padmanbhan for his suggested workaround. This is really helpful and not a really well-known feature.
          The unresolved variables are already addressed by MNG-2971 which is still the showstopper here. Your further workarounds might work, but this should really be fixed in maven itself as everybody will run into such problem then and needs to do silly workarounds.

          Please also see here:

          http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance

          Show
          Jörg Hohwiller added a comment - Thanks to Abhishekh Padmanbhan for his suggested workaround. This is really helpful and not a really well-known feature. The unresolved variables are already addressed by MNG-2971 which is still the showstopper here. Your further workarounds might work, but this should really be fixed in maven itself as everybody will run into such problem then and needs to do silly workarounds. Please also see here: http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
          Hide
          Jörg Hohwiller added a comment -

          Sorry guys, this is no proper workaround. See MNG-4060

          Show
          Jörg Hohwiller added a comment - Sorry guys, this is no proper workaround. See MNG-4060
          Hide
          Jochen Stiepel added a comment -

          Jörg,
          please take a look here http://maven.apache.org/pom.html#Profiles
          you can place the profiles inside the pom.xml.

          Show
          Jochen Stiepel added a comment - Jörg, please take a look here http://maven.apache.org/pom.html#Profiles you can place the profiles inside the pom.xml.
          Hide
          Jörg Hohwiller added a comment -

          @Jochen:
          Thanks for your suggestion but this will not help me. I know profiles very well.
          I could also directly hack all the module-versions as properties in the toplevel POM without any profiles.
          Then I would need MNG-2971 to be resolved.
          The problem is that I do not want to release all parent POMs if a child shall be released.
          All I want is that I can update the version of a child in one single place instead of also spreading this
          version-string all over my pom.xml files. I maintain various projects with maven that have 50-100 pom.xml
          files.
          See also MNG-4161

          Show
          Jörg Hohwiller added a comment - @Jochen: Thanks for your suggestion but this will not help me. I know profiles very well. I could also directly hack all the module-versions as properties in the toplevel POM without any profiles. Then I would need MNG-2971 to be resolved. The problem is that I do not want to release all parent POMs if a child shall be released. All I want is that I can update the version of a child in one single place instead of also spreading this version-string all over my pom.xml files. I maintain various projects with maven that have 50-100 pom.xml files. See also MNG-4161
          Hide
          James Selvakumar added a comment - - edited

          Since support for profiles.xml might be removed in future versions (Ref: MNG-4060) (or was it removed already?), I'm proposing another workaround for the desperate hearts. This makes use of the "relativePath" attribute of parent.

          NOTE: This has the same drawback as using profiles.xml, but it might help some of you.

          This example assumes you have the following directory structure:

           - pom.xml
             - yourapp-child-a
               - pom.xml
             - yourapp-child-b
               - pom.xml
          

          Define your parent pom's version as "FIXED" and define a custom version property.

           <project>
              <modelVersion>4.0.0</modelVersion>
              <groupId>org.yourapp</groupId>
              <artifactId>yourapp-parent</artifactId>
              <packaging>pom</packaging>
              <version>FIXED</version>
          
              <properties>
               <yourapp.version>1.0-SNAPSHOT</yourapp.version>
              </properties>
           </project>
          

          And now the pom for "child-a" would look like the following:

           <project>
              <modelVersion>4.0.0</modelVersion>
              <groupId>org.yourapp</groupId>
              <artifactId>yourapp-child-a</artifactId>
              <packaging>jar</packaging>
              <version>${yourapp.version}</version>
          
              <parent>
                  <groupId>org.yourapp</groupId>
                  <artifactId>yourapp-parent</artifactId>
                  <version>FIXED</version>        
                  <relativePath>..</relativePath>
              </parent>
           </project> 
          

          Same logic applies for "child-b" as well.

          Requirements:
          For the above suggestion to work, your parent pom and modules should be in a single repository

          Advantage:
          This would effectively let you define your version in only the parent

          Disadvantage:
          Modules defined like this cannot be used as "libraries" in other modules that live in a separate repository because of MNG-2971

          Show
          James Selvakumar added a comment - - edited Since support for profiles.xml might be removed in future versions (Ref: MNG-4060 ) (or was it removed already?), I'm proposing another workaround for the desperate hearts. This makes use of the "relativePath" attribute of parent. NOTE: This has the same drawback as using profiles.xml, but it might help some of you. This example assumes you have the following directory structure: - pom.xml - yourapp-child-a - pom.xml - yourapp-child-b - pom.xml Define your parent pom's version as "FIXED" and define a custom version property. <project> <modelVersion>4.0.0</modelVersion> <groupId>org.yourapp</groupId> <artifactId>yourapp-parent</artifactId> <packaging>pom</packaging> <version>FIXED</version> <properties> <yourapp.version>1.0-SNAPSHOT</yourapp.version> </properties> </project> And now the pom for "child-a" would look like the following: <project> <modelVersion>4.0.0</modelVersion> <groupId>org.yourapp</groupId> <artifactId>yourapp-child-a</artifactId> <packaging>jar</packaging> <version>${yourapp.version}</version> <parent> <groupId>org.yourapp</groupId> <artifactId>yourapp-parent</artifactId> <version>FIXED</version> <relativePath>..</relativePath> </parent> </project> Same logic applies for "child-b" as well. Requirements : For the above suggestion to work, your parent pom and modules should be in a single repository Advantage : This would effectively let you define your version in only the parent Disadvantage : Modules defined like this cannot be used as "libraries" in other modules that live in a separate repository because of MNG-2971
          Hide
          Stevo Slavic added a comment -

          Removed my vote for this feature - maven-release-plugin does a great job, and I really don't mind any more to have parent version in modules which inherit it. Parent module reference, like any other dependency, for reproducibility and clarity it's best to have it fully defined.

          Show
          Stevo Slavic added a comment - Removed my vote for this feature - maven-release-plugin does a great job, and I really don't mind any more to have parent version in modules which inherit it. Parent module reference, like any other dependency, for reproducibility and clarity it's best to have it fully defined.
          Hide
          Eduardo Souza added a comment -

          Hello,

          I work in a product that includes 150 projects. The projects are divided into groups of four projects that comprise a system module.

          Today we work with maven 2.2.1 modified to not check the version of the parent project. When conducting any activity the child accesses the tag design <relativepath> and see who is the parent project that he is using. With this modification we can work normally without having to do a checkout of nearly 1GB of projects to replace the version with each new release.

          From my point of view, when working this way, the parent project does control projects.

          The idea of declaring the version of the parent in the projects is valid when it has a small number of projects, but when you have a large number of projects, this activity is not feasible.

          Show
          Eduardo Souza added a comment - Hello, I work in a product that includes 150 projects. The projects are divided into groups of four projects that comprise a system module. Today we work with maven 2.2.1 modified to not check the version of the parent project. When conducting any activity the child accesses the tag design <relativepath> and see who is the parent project that he is using. With this modification we can work normally without having to do a checkout of nearly 1GB of projects to replace the version with each new release. From my point of view, when working this way, the parent project does control projects. The idea of declaring the version of the parent in the projects is valid when it has a small number of projects, but when you have a large number of projects, this activity is not feasible.
          Hide
          Edward Staub added a comment - - edited

          I'm going to be evangelizing Maven to my dev group, where we have a similarly-sized code base, build using Ant. This ("WE HAVE TO EDIT EVERY BUILDFILE ON EVERY RELEASE?!?") is the kind of thing that makes conversion hard to get consensus on - conservatives latch onto them and wave them around as "show-stoppers", whether true or not.

          Show
          Edward Staub added a comment - - edited I'm going to be evangelizing Maven to my dev group, where we have a similarly-sized code base, build using Ant. This ("WE HAVE TO EDIT EVERY BUILDFILE ON EVERY RELEASE?!?") is the kind of thing that makes conversion hard to get consensus on - conservatives latch onto them and wave them around as "show-stoppers", whether true or not.
          Hide
          Dennis Lundberg added a comment -

          Edward,

          If you use Maven Release Plugin, it will do this (update the parent version in every project's build file) for you.

          Show
          Dennis Lundberg added a comment - Edward, If you use Maven Release Plugin, it will do this (update the parent version in every project's build file) for you.
          Hide
          Edward Staub added a comment -

          Dennis, sorry, I wasn't clear. I know about the release plugin.
          Regardless of automation of the editing itself, for large workspaces, this is not a good solution.

          See http://stackoverflow.com/questions/6109814/when-should-mvn-release-be-used-in-the-project-lifecycle for the problems with bulk-renumbering as seen by a current and apparently experienced Maven user.

          We put out three numbered builds a week, and have hundreds of projects. The numbers are used to track where defects are found and where they are fixed - snapshots are not an option, unless we use snapshots with some other numbering system. A need to change hundreds of POMs - automated or not - on every build is not likely to be well-received. Just the accumulation of 10,000+ junk POM versions per year in the version-control system is even a bit of a problem.

          Show
          Edward Staub added a comment - Dennis, sorry, I wasn't clear. I know about the release plugin. Regardless of automation of the editing itself, for large workspaces, this is not a good solution. See http://stackoverflow.com/questions/6109814/when-should-mvn-release-be-used-in-the-project-lifecycle for the problems with bulk-renumbering as seen by a current and apparently experienced Maven user. We put out three numbered builds a week, and have hundreds of projects. The numbers are used to track where defects are found and where they are fixed - snapshots are not an option, unless we use snapshots with some other numbering system. A need to change hundreds of POMs - automated or not - on every build is not likely to be well-received. Just the accumulation of 10,000+ junk POM versions per year in the version-control system is even a bit of a problem.
          Hide
          Luke Lu added a comment -

          Allowing versions (especially parent version) to be specified by properties is critical for continuous integration of large projects with many modules. CI needs a unique version number for each build. Complex CI setups have multiple profiles and builds per profile combination. Having to edit pom files (even via a release plugin) is ridiculous, as it's basically denormalize perfectly good poms into thousands of interpolated poms with no essential code changes.

          Show
          Luke Lu added a comment - Allowing versions (especially parent version) to be specified by properties is critical for continuous integration of large projects with many modules. CI needs a unique version number for each build. Complex CI setups have multiple profiles and builds per profile combination. Having to edit pom files (even via a release plugin) is ridiculous, as it's basically denormalize perfectly good poms into thousands of interpolated poms with no essential code changes.
          Hide
          Hans-Peter Störr added a comment -

          Luke, I agree very much. Would the approach of denoting the parent pom by relativepath, as suggested above, work for you? The version numbers would then be defined in the parent pom that must be available under the given path. I guess this is much cleaner than using properties.

          Show
          Hans-Peter Störr added a comment - Luke, I agree very much. Would the approach of denoting the parent pom by relativepath, as suggested above, work for you? The version numbers would then be defined in the parent pom that must be available under the given path. I guess this is much cleaner than using properties.
          Hide
          Luke Lu added a comment -

          Would the approach of denoting the parent pom by relativepath, as suggested above, work for you?

          No. relativePath doesn't seem to make any sense for deployed artifacts (i.e., no source/build tree). e.g., if you have a client and a server modules with a common parent and that downstream projects need to depend on the client jar, an explicit version (either client version or the parent version) in the client pom is required to get to the right parent pom.

          Show
          Luke Lu added a comment - Would the approach of denoting the parent pom by relativepath, as suggested above, work for you? No. relativePath doesn't seem to make any sense for deployed artifacts (i.e., no source/build tree). e.g., if you have a client and a server modules with a common parent and that downstream projects need to depend on the client jar, an explicit version (either client version or the parent version) in the client pom is required to get to the right parent pom.
          Hide
          Stanilslav Spiridonov added a comment - - edited

          I have one idea.

          The main point of parent POM is collect all similar modules settings (property, dependency, plugins, etc.) in one place (with possible hierarchy) and make the DEVELOPMENT of project with multiple project more simple. All these have sense only on source level. After the build and install/deploy artifact to local or remote repository the parents poms only produce complications without any additional value (is not?). So my suggestion is to install/deploy artifacts with effective POM, now the real one. So the parent pom will exist only on source level and disappear in produced artifact. It is backward compatible with current implementation and will not break anything in existing projects.

          May be is is stupid, but I believe it will simplify the issue with parent POM and will allow to find the right solution. For example after that the SNAPSHOTS artifact will not refereeing the SNAPSHOT parent, so even SNAPSHOTS will be more fixed and stable.

          Show
          Stanilslav Spiridonov added a comment - - edited I have one idea. The main point of parent POM is collect all similar modules settings (property, dependency, plugins, etc.) in one place (with possible hierarchy) and make the DEVELOPMENT of project with multiple project more simple. All these have sense only on source level. After the build and install/deploy artifact to local or remote repository the parents poms only produce complications without any additional value (is not?). So my suggestion is to install/deploy artifacts with effective POM, now the real one. So the parent pom will exist only on source level and disappear in produced artifact. It is backward compatible with current implementation and will not break anything in existing projects. May be is is stupid, but I believe it will simplify the issue with parent POM and will allow to find the right solution. For example after that the SNAPSHOTS artifact will not refereeing the SNAPSHOT parent, so even SNAPSHOTS will be more fixed and stable.
          Hide
          Christian Lewold added a comment -

          This is a valid issue, but there is a simple workaround:

          parent pom.xml
          <project ....>
            <properties>
              <currentVersion>0.0.2-SNAPSHOT</currentVersion>
            </properties>
            <artifactId>parent</artifactId>
            <groupId>my.group</groupId>
            <version>${currentVersion}</version>
            <modules>
              <module>../child</module>
            </modules>
            ....
          </project>
          

          and in all childs you use

          child pom.xml
          <project ....>
            <parent>
              <groupId>my.group</groupId>
              <artifactId>parent</artifactId>
              <version>${currentVersion}</version>
              <relativePath>../parent/pom.xml</relativePath>
            </parent>
            <artifactId>child</artifactId> 
            ....
          </project>
          

          This way you just need to change the version once within the properties section of the parent pom.

          Hope this helps some out there, as I was searching for a solution for days.

          Chris

          Show
          Christian Lewold added a comment - This is a valid issue, but there is a simple workaround: parent pom.xml <project ....> <properties> <currentVersion>0.0.2-SNAPSHOT</currentVersion> </properties> <artifactId>parent</artifactId> <groupId>my.group</groupId> <version>${currentVersion}</version> <modules> <module>../child</module> </modules> .... </project> and in all childs you use child pom.xml <project ....> <parent> <groupId>my.group</groupId> <artifactId>parent</artifactId> <version>${currentVersion}</version> <relativePath>../parent/pom.xml</relativePath> </parent> <artifactId>child</artifactId> .... </project> This way you just need to change the version once within the properties section of the parent pom. Hope this helps some out there, as I was searching for a solution for days. Chris
          Hide
          Andrew Logvinov added a comment -

          Chris, I've been using this approach for quite a long time because it seemed great - you only need to specify version once, in a property, and you can reference it wherever you like.

          But recently I came across the problem connected with this approach - see here http://stackoverflow.com/a/3685248. In two words, Maven doesn't substitute property reference into property value in project.version when installing or deploying artifact which leads to problems if some other project depends on this artifact.

          Show
          Andrew Logvinov added a comment - Chris, I've been using this approach for quite a long time because it seemed great - you only need to specify version once, in a property, and you can reference it wherever you like. But recently I came across the problem connected with this approach - see here http://stackoverflow.com/a/3685248 . In two words, Maven doesn't substitute property reference into property value in project.version when installing or deploying artifact which leads to problems if some other project depends on this artifact.
          Hide
          Christian Lewold added a comment -

          Andrew - I don't know if I understand you correct. If I do a "mvn clean install" on my parent project, all the modules are installed in the local repo with the correct property substituted.

          But actually this is all a mess. I'm quite new to maven, but I'm not that impressed right now, as such very basic things simply don't work. I mean face it - maven claims it wants to reduce effort, and then people are forced to update version numbers in ALL poms every time the version changes.

          Up to now I found nothing which cannot be achieved by well written ant scripts (central script containing the logic with small scripts importing the central one).

          Ok this particular problem seems to be solved with Maven 3.1 - a problem which is like 7 years old, and where noone seems to know when 3.1 finally arrives .....

          Up to this point I try to live with the workaround, as I'm not in the mood to change like 20 pom.xml files every time I change the version (yes, yes there is the release plugin - but that's still just a workaround for a messy concept)

          Show
          Christian Lewold added a comment - Andrew - I don't know if I understand you correct. If I do a "mvn clean install" on my parent project, all the modules are installed in the local repo with the correct property substituted. But actually this is all a mess. I'm quite new to maven, but I'm not that impressed right now, as such very basic things simply don't work. I mean face it - maven claims it wants to reduce effort, and then people are forced to update version numbers in ALL poms every time the version changes. Up to now I found nothing which cannot be achieved by well written ant scripts (central script containing the logic with small scripts importing the central one). Ok this particular problem seems to be solved with Maven 3.1 - a problem which is like 7 years old, and where noone seems to know when 3.1 finally arrives ..... Up to this point I try to live with the workaround, as I'm not in the mood to change like 20 pom.xml files every time I change the version (yes, yes there is the release plugin - but that's still just a workaround for a messy concept)
          Hide
          Christian Lewold added a comment -

          Btw. If I'm not mistaken this is the most popular 3.1 issue, and 3.1 seems to come out "someday, but not soon".

          Wouldn't it be an idea to move this issue into 3.0.5 ?

          Show
          Christian Lewold added a comment - Btw. If I'm not mistaken this is the most popular 3.1 issue, and 3.1 seems to come out "someday, but not soon". Wouldn't it be an idea to move this issue into 3.0.5 ?
          Hide
          Gustavo Chaves added a comment -

          There is a discussion going on in the maven users list which that seems relevant. Basically we're discussing how to avoid all that POM editing that has to be done whenever you cut a (release or feature) branch. The release plugin can do the editing for you, when you create a release branch, but it does not help with feature branches that need to be reintegrated later. Also, all that POM editing causes unecessary pain when you do merges, either rebase merges from trunk or reintegration merges to trunk.

          The idea being discussed there is based on the notion that the proper location to record artifact version numbers is in the SCM tool and not in the POM. Basically, maven should be able to derive the artifact version number from the actual SCM tag or branch that the working area is associated to.

          Note that there is not a complete solution yet due to missing funcionality treated in MNG-2971, an issue from which this depends on.

          Show
          Gustavo Chaves added a comment - There is a discussion going on in the maven users list which that seems relevant. Basically we're discussing how to avoid all that POM editing that has to be done whenever you cut a (release or feature) branch. The release plugin can do the editing for you, when you create a release branch, but it does not help with feature branches that need to be reintegrated later. Also, all that POM editing causes unecessary pain when you do merges, either rebase merges from trunk or reintegration merges to trunk. The idea being discussed there is based on the notion that the proper location to record artifact version numbers is in the SCM tool and not in the POM. Basically, maven should be able to derive the artifact version number from the actual SCM tag or branch that the working area is associated to. Note that there is not a complete solution yet due to missing funcionality treated in MNG-2971 , an issue from which this depends on.
          Hide
          Gustavo Chaves added a comment -

          Hi. I propose to link this issue as dependent of (or at least related to) MNG-4223. It's the best researched open issue I could find regarding the need to expand properties in the artifact coordinate tags. (I think it's better researched than MNG-2971 which is already related to this issue.)

          Show
          Gustavo Chaves added a comment - Hi. I propose to link this issue as dependent of (or at least related to) MNG-4223 . It's the best researched open issue I could find regarding the need to expand properties in the artifact coordinate tags. (I think it's better researched than MNG-2971 which is already related to this issue.)
          Hide
          Ian A. added a comment -

          Excellent idea! Sponsored!

          Show
          Ian A. added a comment - Excellent idea! Sponsored!
          Hide
          brianfox brianfox added a comment -

          Tim, Tony, Jira shouldn't be used for advertising of services. The merit of the idea is moot.

          Show
          brianfox brianfox added a comment - Tim, Tony, Jira shouldn't be used for advertising of services. The merit of the idea is moot.
          Hide
          Sebastien Tardif added a comment -

          I agree that Jira shouldn't be used for advertising of services, but since this issue is visibly dragging a lot, even if having so many votes, and that somebody already committed to pay to get the issue resolved, the timing of complaining about this couldn't be worst

          As a positive point, at least it's not the assignee that slowed down a path to resolution.

          Show
          Sebastien Tardif added a comment - I agree that Jira shouldn't be used for advertising of services, but since this issue is visibly dragging a lot, even if having so many votes, and that somebody already committed to pay to get the issue resolved, the timing of complaining about this couldn't be worst As a positive point, at least it's not the assignee that slowed down a path to resolution.
          Hide
          Tony Lampada added a comment -

          Brian, Olivier. My apologies, I didn't mean to sound spammy or anything. I will not post comments like this one on Maven JIRA again. Let me just say that my intentions were pure though

          Show
          Tony Lampada added a comment - Brian, Olivier. My apologies, I didn't mean to sound spammy or anything. I will not post comments like this one on Maven JIRA again. Let me just say that my intentions were pure though
          Hide
          Tony Lampada added a comment -

          Ah, just one question though.

          FreedomSponsors encourages users to post back on the original tracker when they sponsor new offers. That is the only way that developers can be notified about the offers.

          If people start to sponsor Maven issues and tell about it on Maven JIRA, will those comments be deleted as well?

          Show
          Tony Lampada added a comment - Ah, just one question though. FreedomSponsors encourages users to post back on the original tracker when they sponsor new offers. That is the only way that developers can be notified about the offers. If people start to sponsor Maven issues and tell about it on Maven JIRA, will those comments be deleted as well?
          Hide
          Olivier Lamy added a comment -

          Probably yes.
          Please post here only patches or technical comments on issues.

          Show
          Olivier Lamy added a comment - Probably yes. Please post here only patches or technical comments on issues.
          Hide
          Adrian Shum added a comment - - edited

          For all suggestion/workaround proposed here using a property for parent version, they all suffer from one issue: This will work for build, but will fail on using the result as dependency.

          Assuming I have a very simple structure like this:

          foo-parent
          foo-lib
          

          assume the POm of foo-lib contains

              <parent>
                  <groupId>foo</groupId>
                  <artifactId>foo-parent</artifactId>
                  <version>${foo.version}</version>
                  <relativePath>../foo-parent/pom.xml</relativePath>
              </parent>
          

          (foo.version can be provided by any means, by command line or by property defined in parent etc)

          Because Maven is deploying/installing the POM as-is. That means, if I put foo-lib in the repository, when people is using it as dependency, the POM is containing only

          ${foo.version} 

          string literal as the parent version. There is no way that it can resolve the correct parent POM to refer to.

          May I suggests, instead of deploying the POM as-is, we are creating an "effective" POM to use to deploy? In the "effective" POM, we have all necessary properties replaced and use that for install/deploy.

          Show
          Adrian Shum added a comment - - edited For all suggestion/workaround proposed here using a property for parent version, they all suffer from one issue: This will work for build, but will fail on using the result as dependency. Assuming I have a very simple structure like this: foo-parent foo-lib assume the POm of foo-lib contains <parent> <groupId>foo</groupId> <artifactId>foo-parent</artifactId> <version>${foo.version}</version> <relativePath>../foo-parent/pom.xml</relativePath> </parent> (foo.version can be provided by any means, by command line or by property defined in parent etc) Because Maven is deploying/installing the POM as-is. That means, if I put foo-lib in the repository, when people is using it as dependency, the POM is containing only ${foo.version} string literal as the parent version. There is no way that it can resolve the correct parent POM to refer to. May I suggests, instead of deploying the POM as-is, we are creating an "effective" POM to use to deploy? In the "effective" POM, we have all necessary properties replaced and use that for install/deploy.
          Hide
          Stanilslav Spiridonov added a comment -

          I suggested it 2 years ago (https://jira.codehaus.org/browse/MNG-624?focusedCommentId=287554&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-287554)

          Anyway I completely agree with you. Deploying the effective POM will not solve the whole issue, but will allow to separate the parent issue on independent parts and solve at least the deployment. I think it will be a right step

          Show
          Stanilslav Spiridonov added a comment - I suggested it 2 years ago ( https://jira.codehaus.org/browse/MNG-624?focusedCommentId=287554&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-287554 ) Anyway I completely agree with you. Deploying the effective POM will not solve the whole issue, but will allow to separate the parent issue on independent parts and solve at least the deployment. I think it will be a right step
          Hide
          Eduardo Souza added a comment -

          Maybe this issues can partially correct this problem.

          https://jira.codehaus.org/browse/MNG-2971

          https://jira.codehaus.org/browse/MNG-4223

          They are to be reviewed for 3.x...

          Show
          Eduardo Souza added a comment - Maybe this issues can partially correct this problem. https://jira.codehaus.org/browse/MNG-2971 https://jira.codehaus.org/browse/MNG-4223 They are to be reviewed for 3.x...
          Hide
          Jörg Hohwiller added a comment -

          while this feature would be still desirable there is a workaround possible with consumer-maven-plugin:
          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

          What you can now do is keep all the versions of your parent POMs fixed and consider them as development artifacts that will not be relevant for end-users of your artifacts. If you use consumer-maven-plugin it will generate a "minified" POM with variables and dependencies resolved and without parent POM relation, etc. This allows you to define variables, dependency management, etc. in your parent POMs but bump the final GAV coordinates and dependencies of your child/leaf modules on install/deploy.

          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 - while this feature would be still desirable there is a workaround possible with consumer-maven-plugin: 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 What you can now do is keep all the versions of your parent POMs fixed and consider them as development artifacts that will not be relevant for end-users of your artifacts. If you use consumer-maven-plugin it will generate a "minified" POM with variables and dependencies resolved and without parent POM relation, etc. This allows you to define variables, dependency management, etc. in your parent POMs but bump the final GAV coordinates and dependencies of your child/leaf modules on install/deploy. 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 -

          For the workaround have a look here:
          http://mojo.codehaus.org/flatten-maven-plugin/examples/example-multiple-versions.html

          2nd release is out in central repo. Just add this to your top-level POM 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 - For the workaround have a look here: http://mojo.codehaus.org/flatten-maven-plugin/examples/example-multiple-versions.html 2nd release is out in central repo. Just add this to your top-level POM build section: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>flatten-maven-plugin</artifactId> <version>1.0.0-beta-2</version> </plugin>

            People

            • Assignee:
              Unassigned
              Reporter:
              Brett Porter
            • Votes:
              317 Vote for this issue
              Watchers:
              226 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 4 hours
                4h
                Remaining:
                Remaining Estimate - 4 hours
                4h
                Logged:
                Time Spent - Not Specified
                Not Specified