[
https://issues.apache.org/jira/browse/MRELEASE-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MRELEASE-943:
----------------------------------------
Description:
Edit/Note: this task has been split in 3 other tickets (linked), please keep
this one as an umbrella task to ensure the goal is complete and not partially
fixed only
In current version of maven-release-manager, the project version is quite
strict and several cases are not handled preventing mvn release plugin to be
used:
1- version aliases (<foo.version>${project.version}</foo.version>), it can
makes sense to use that in some projects and is sometimes a way to avoid to
spend nights rewriting multiple poms. This is ignored in hierarchic projects
(at least 2 or 3 levels).
2- children not listing the parent. If the parent list children and children
doesn't list the parent cause the goal is to let them be checkout directly then
the child version is not handled by the mvn release plugin at all.
3- support autoVersionModules with multiple versions (just removing SNAPSHOT
instead of applying parent version to all poms)
Would be great to at least have a flag to support 2 and detect properly or have
a list of tolerated expressions as alias of the project version in the plugin
(= tolerate 1). 3 is a nice to have.
Note: if it can help tomee project does it and the number of poms - ~251 poms
(144 follow rule 2) - justified historically the rule 1.
was:
In current version of maven-release-manager, the project version is quite
strict and several cases are not handled preventing mvn release plugin to be
used:
1- version aliases (<foo.version>${project.version}</foo.version>), it can
makes sense to use that in some projects and is sometimes a way to avoid to
spend nights rewriting multiple poms. This is ignored in hierarchic projects
(at least 2 or 3 levels).
2- children not listing the parent. If the parent list children and children
doesn't list the parent cause the goal is to let them be checkout directly then
the child version is not handled by the mvn release plugin at all.
3- support autoVersionModules with multiple versions (just removing SNAPSHOT
instead of applying parent version to all poms)
Would be great to at least have a flag to support 2 and detect properly or have
a list of tolerated expressions as alias of the project version in the plugin
(= tolerate 1). 3 is a nice to have.
Note: if it can help tomee project does it and the number of poms - ~251 poms
(144 follow rule 2) - justified historically the rule 1.
> be more tolerant with project version
> -------------------------------------
>
> Key: MRELEASE-943
> URL: https://issues.apache.org/jira/browse/MRELEASE-943
> Project: Maven Release Plugin
> Issue Type: Bug
> Reporter: Romain Manni-Bucau
> Priority: Major
>
> Edit/Note: this task has been split in 3 other tickets (linked), please keep
> this one as an umbrella task to ensure the goal is complete and not partially
> fixed only
> In current version of maven-release-manager, the project version is quite
> strict and several cases are not handled preventing mvn release plugin to be
> used:
> 1- version aliases (<foo.version>${project.version}</foo.version>), it can
> makes sense to use that in some projects and is sometimes a way to avoid to
> spend nights rewriting multiple poms. This is ignored in hierarchic projects
> (at least 2 or 3 levels).
> 2- children not listing the parent. If the parent list children and children
> doesn't list the parent cause the goal is to let them be checkout directly
> then the child version is not handled by the mvn release plugin at all.
> 3- support autoVersionModules with multiple versions (just removing SNAPSHOT
> instead of applying parent version to all poms)
> Would be great to at least have a flag to support 2 and detect properly or
> have a list of tolerated expressions as alias of the project version in the
> plugin (= tolerate 1). 3 is a nice to have.
> Note: if it can help tomee project does it and the number of poms - ~251 poms
> (144 follow rule 2) - justified historically the rule 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
