[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Morris updated MNG-624: Attachment: Maven_overrides_for_dynamic_parent_version_MGS.zip automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven Issue Type: Improvement Components: FDPFC, Inheritance and Interpolation Reporter: Brett Porter Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: Maven_overrides_for_dynamic_parent_version_MGS.zip, MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359597#comment-359597
]
Mark Morris edited comment on MNG-624 at 12/23/14 4:29 PM:
---
If anyone's looking for a custom solution for this issue, we implemented a
modification in-house that allows you to replace your pom.xml parent versions
with a dynamic value. You basically drop an aaa-mgs-maven-overrides.jar into
your apache-maven\lib directory which then intercepts the parent version right
when it's read (and replaces it with a properties file value). You can take a
look at the attached Maven_overrides_for_dynamic_parent_version_MGS.zip file
for the details (and the jar) but here is everything at a high level (posted
with permission from my director at Monster Government Solutions):
1) Change your pom.xml parent versions to look like this (all our sub-projects
use this):
parent
groupIdcom.monster.mgs.terra/groupId
artifactIdterra-parent/artifactId
version$MGS{branch_configs/branch.properties#snapshot.version}/version
relativePath../../terra/terra-parent/pom.xml/relativePath
/parent
2) Create a single root-level branch_configs folder with a branch.properties
file containing property snapshot.version=ABC-SNAPSHOT (these can be modified
to your values)
Now when you run any maven command, the custom code will detect the $MGS{}
string and replace it with the value from your properties file. The overrides
jar contains modified versions of the maven MavenXpp3Reader and
MavenXpp3ReaderEx classes and replaces functionality in their
getTrimmedValue(String) methods (which is called for almost every value in the
poms). Theoretically this approach could be used in the actual maven source as
a permanent implementation option but you'd want to use something more generic
than $MGS{} and you'd probably want to pass in the pom.xml's file location
(to reduce complexity, this overrides jar doesn't handle relative paths).
There are also a couple other steps that are needed when using IntelliJ and
Jenkins (these steps are detailed in the
Dynamic_Parent_Version_MGS_Wiki_Page.pdf in the
Maven_overrides_for_dynamic_parent_version_MGS.zip ). This approach got rid of
all our merge headaches when merging between branches (with over 90 pom.xmls in
sub-projects) so hopefully this will be useful to others as well. Also thanks
in advance if this or something like it is put into the actual maven codebase.
Thanks,
Mark Morris.
was (Author: morrism):
If anyone?s looking for a custom solution for this issue, we implemented a
modification in-house that allows you to replace your pom.xml parent versions
with a dynamic value. You basically drop an aaa-mgs-maven-overrides.jar into
your apache-maven\lib directory which then intercepts the parent version right
when it's read (and replaces it with a properties file value). You can take a
look at the attached Maven_overrides_for_dynamic_parent_version_MGS.zip file
for the details (and the jar) but here is everything at a high level (posted
with permission from my director at Monster Government Solutions):
1) Change your pom.xml parent versions to look like this (all our sub-projects
use this):
parent
groupIdcom.monster.mgs.terra/groupId
artifactIdterra-parent/artifactId
version$MGS{branch_configs/branch.properties#snapshot.version}/version
relativePath../../terra/terra-parent/pom.xml/relativePath
/parent
2) Create a single root-level branch_configs folder with a branch.properties
file containing property snapshot.version=ABC-SNAPSHOT (these can be modified
to your values)
Now when you run any maven command, the custom code will detect the $MGS{}
string and replace it with the value from your properties file. The overrides
jar contains modified versions of the maven MavenXpp3Reader and
MavenXpp3ReaderEx classes and replaces functionality in their
getTrimmedValue(String) methods (which is called for almost every value in the
poms). Theoretically this approach could be used in the actual maven source as
a permanent implementation option but you'd want to use something more generic
than $MGS{} and you'd probably want to pass in the pom.xml's file location
(to reduce complexity, this overrides jar doesn't handle relative paths).
There are also a couple other steps that are needed when using IntelliJ and
Jenkins (these steps are detailed in the
Dynamic_Parent_Version_MGS_Wiki_Page.pdf in the
Maven_overrides_for_dynamic_parent_version_MGS.zip ). This approach got rid of
all our merge headaches when merging between branches (with over 90 pom.xmls in
sub-projects) so hopefully this will be useful to others as well. Also thanks
in advance if this or something like it is put into the actual maven codebase.
Thanks,
Mark Morris.
automatic parent versioning
---
[jira] (MNG-624) automatic parent versioning
[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359597#comment-359597
]
Mark Morris commented on MNG-624:
-
If anyone?s looking for a custom solution for this issue, we implemented a
modification in-house that allows you to replace your pom.xml parent versions
with a dynamic value. You basically drop an aaa-mgs-maven-overrides.jar into
your apache-maven\lib directory which then intercepts the parent version right
when it's read (and replaces it with a properties file value). You can take a
look at the attached Maven_overrides_for_dynamic_parent_version_MGS.zip file
for the details (and the jar) but here is everything at a high level (posted
with permission from my director at Monster Government Solutions):
1) Change your pom.xml parent versions to look like this (all our sub-projects
use this):
parent
groupIdcom.monster.mgs.terra/groupId
artifactIdterra-parent/artifactId
version$MGS{branch_configs/branch.properties#snapshot.version}/version
relativePath../../terra/terra-parent/pom.xml/relativePath
/parent
2) Create a single root-level branch_configs folder with a branch.properties
file containing property snapshot.version=ABC-SNAPSHOT (these can be modified
to your values)
Now when you run any maven command, the custom code will detect the $MGS{}
string and replace it with the value from your properties file. The overrides
jar contains modified versions of the maven MavenXpp3Reader and
MavenXpp3ReaderEx classes and replaces functionality in their
getTrimmedValue(String) methods (which is called for almost every value in the
poms). Theoretically this approach could be used in the actual maven source as
a permanent implementation option but you'd want to use something more generic
than $MGS{} and you'd probably want to pass in the pom.xml's file location
(to reduce complexity, this overrides jar doesn't handle relative paths).
There are also a couple other steps that are needed when using IntelliJ and
Jenkins (these steps are detailed in the
Dynamic_Parent_Version_MGS_Wiki_Page.pdf in the
Maven_overrides_for_dynamic_parent_version_MGS.zip ). This approach got rid of
all our merge headaches when merging between branches (with over 90 pom.xmls in
sub-projects) so hopefully this will be useful to others as well. Also thanks
in advance if this or something like it is put into the actual maven codebase.
Thanks,
Mark Morris.
automatic parent versioning
---
Key: MNG-624
URL: https://jira.codehaus.org/browse/MNG-624
Project: Maven
Issue Type: Improvement
Components: FDPFC, Inheritance and Interpolation
Reporter: Brett Porter
Priority: Blocker
Fix For: Issues to be reviewed for 4.x
Attachments: Maven_overrides_for_dynamic_parent_version_MGS.zip,
MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
Original Estimate: 4 hours
Remaining Estimate: 4 hours
(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.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-624: --- Component/s: FDPFC automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven Issue Type: Improvement Components: FDPFC, Inheritance and Interpolation Reporter: Brett Porter Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347644#comment-347644 ] Jörg Hohwiller commented on MNG-624: 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 groupIdorg.codehaus.mojo/groupId artifactIdflatten-maven-plugin/artifactId version1.0.0-beta-2/version /plugin automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=343841#comment-343841 ] Jörg Hohwiller commented on MNG-624: Plugin had to be renamed: http://mojo.codehaus.org/flatten-maven-plugin/ automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-624: -- Assignee: (was: Ralph Goers) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl reassigned MNG-624: - Assignee: Jason van Zyl automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Jason van Zyl Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl reassigned MNG-624: - Assignee: (was: Jason van Zyl) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342592#comment-342592 ] Jörg Hohwiller commented on MNG-624: 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 groupIdorg.codehaus.mojo/groupId artifactIdconsumer-maven-plugin/artifactId version1.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). automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-624: - Fix Version/s: (was: 3.2) Issues to be reviewed for 4.x automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: Issues to be reviewed for 4.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=336980#comment-336980
]
Adrian Shum commented on MNG-624:
-
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:
{code}
foo-parent
foo-lib
{code}
assume the POm of foo-lib contains
{code}
parent
groupIdfoo/groupId
artifactIdfoo-parent/artifactId
version${foo.version}/version
relativePath../foo-parent/pom.xml/relativePath
/parent
{code}
(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.
automatic parent versioning
---
Key: MNG-624
URL: https://jira.codehaus.org/browse/MNG-624
Project: Maven 2 3
Issue Type: Improvement
Components: Inheritance and Interpolation
Reporter: Brett Porter
Assignee: Ralph Goers
Priority: Blocker
Fix For: 3.2
Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
Original Estimate: 4 hours
Remaining Estimate: 4 hours
(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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=336980#comment-336980
]
Adrian Shum edited comment on MNG-624 at 12/9/13 3:44 AM:
--
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:
{code}
foo-parent
foo-lib
{code}
assume the POm of foo-lib contains
{code}
parent
groupIdfoo/groupId
artifactIdfoo-parent/artifactId
version${foo.version}/version
relativePath../foo-parent/pom.xml/relativePath
/parent
{code}
(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
{code}${foo.version} {code}
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.
was (Author: adrianshum):
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:
{code}
foo-parent
foo-lib
{code}
assume the POm of foo-lib contains
{code}
parent
groupIdfoo/groupId
artifactIdfoo-parent/artifactId
version${foo.version}/version
relativePath../foo-parent/pom.xml/relativePath
/parent
{code}
(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.
automatic parent versioning
---
Key: MNG-624
URL: https://jira.codehaus.org/browse/MNG-624
Project: Maven 2 3
Issue Type: Improvement
Components: Inheritance and Interpolation
Reporter: Brett Porter
Assignee: Ralph Goers
Priority: Blocker
Fix For: 3.2
Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
Original Estimate: 4 hours
Remaining Estimate: 4 hours
(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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=336984#comment-336984 ] Stanilslav Spiridonov commented on MNG-624: --- I suggested it 2 years ago :) (https://jira.codehaus.org/browse/MNG-624?focusedCommentId=287554page=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 :) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=336985#comment-336985 ] Eduardo Souza commented on MNG-624: --- 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... automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311947#comment-311947 ] Tony Lampada commented on MNG-624: -- Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311972#comment-311972 ] Ian A. commented on MNG-624: Excellent idea! Sponsored! automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-624: - Comment: was deleted (was: Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it.) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311987#comment-311987 ] Tim McCune commented on MNG-624: Change By: Olivier Lamy (22/Oct/12 2:39 PM) Deleted Comment:Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it. Hey Olivier, just curious, why did you delete that comment? Seems like a good idea... automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-624: -- Comment: was deleted (was: Change By:Olivier Lamy (22/Oct/12 2:39 PM) Deleted Comment:Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it. Hey Olivier, just curious, why did you delete that comment? Seems like a good idea...) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311989#comment-311989 ] Brian Fox commented on MNG-624: --- Tim, Tony, Jira shouldn't be used for advertising of services. The merit of the idea is moot. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311992#comment-311992 ] Sebastien Tardif commented on MNG-624: -- 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. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311996#comment-311996 ] Tony Lampada commented on MNG-624: -- 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 :-) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311997#comment-311997 ] Tony Lampada commented on MNG-624: -- 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? automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311998#comment-311998 ] Olivier Lamy commented on MNG-624: -- Probably yes. Please post here only patches or technical comments on issues. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294133#comment-294133 ] Gustavo Chaves commented on MNG-624: 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.) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=293785#comment-293785 ] Gustavo Chaves commented on MNG-624: There is a [discussion going on|http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tc5543110.html] 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. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=291255#comment-291255 ] Christian Lewold commented on MNG-624: -- 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 ? automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=291110#comment-291110 ] Christian Lewold commented on MNG-624: -- 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) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=290789#comment-290789 ] Andrew Logvinov commented on MNG-624: - 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. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=290606#comment-290606
]
Christian Lewold commented on MNG-624:
--
This is a valid issue, but there is a simple workaround:
{code:title=parent pom.xml}
project
properties
currentVersion0.0.2-SNAPSHOT/currentVersion
/properties
artifactIdparent/artifactId
groupIdmy.group/groupId
version${currentVersion}/version
modules
module../child/module
/modules
/project
{code}
and in all childs you use
{code:title=child pom.xml}
project
parent
groupIdmy.group/groupId
artifactIdparent/artifactId
version${currentVersion}/version
relativePath../parent/pom.xml/relativePath
/parent
artifactIdchild/artifactId
/project
{code}
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
automatic parent versioning
---
Key: MNG-624
URL: https://jira.codehaus.org/browse/MNG-624
Project: Maven 2 3
Issue Type: Improvement
Components: Inheritance and Interpolation
Reporter: Brett Porter
Assignee: Ralph Goers
Priority: Blocker
Fix For: 3.1
Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
Original Estimate: 4 hours
Remaining Estimate: 4 hours
(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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=287554#comment-287554 ] Stanilslav Spiridonov commented on MNG-624: --- 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 install deploy artifacts with effective POM, now the real. So the parent poms 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. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=287554#comment-287554 ] Stanilslav Spiridonov edited comment on MNG-624 at 1/5/12 4:40 PM: --- 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. was (Author: foal): 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 install deploy artifacts with effective POM, now the real. So the parent poms 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. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
