[
https://issues.apache.org/jira/browse/MNG-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17730405#comment-17730405
]
ASF GitHub Bot commented on MNG-7804:
-------------------------------------
gnodet commented on code in PR #1147:
URL: https://github.com/apache/maven/pull/1147#discussion_r1222505682
##########
api/maven-api-model/src/main/mdo/maven.mdo:
##########
@@ -2646,6 +2646,15 @@
]]>
</description>
</field>
+ <field>
+ <name>priority</name>
+ <version>4.2.0+</version>
Review Comment:
> it is the convention that has been defined from the beginning for the
whole consumer ecosystem, and the reason build bom vs consumer pom has been
introduced
https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
>
> we can test options and go back to the M dev ML to have feedback from
others: this change is not only about our internal code
I think the initial assumption and driver for the build/consumer feature,
i.e. that "changing the POM version and publishing artifacts on Maven Central
with this new model would break consumers using either older Maven versions or
other build tools" was done with a wrong assumption. I'll double check with
more tests, but afaik, consumers using old versions of maven won't be broken
when _using_ the artifacts as a dependency (they would be broken if using such
a project as a parent though). So yes, this definitely would mean that if you
use a 4.2.0 modelVersion (though you should not be forced to unless you
actually need something in it) imposes to use a recent maven when building a
project that inherit it.
I'm not sure about other tools.
Anyway, I'll send a mail to dev@ to discuss that.
> add flexible goal ordering in phase
> -----------------------------------
>
> Key: MNG-7804
> URL: https://issues.apache.org/jira/browse/MNG-7804
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
> Affects Versions: 3.0, 3.9.2, 4.0.0-alpha-5
> Reporter: Herve Boutemy
> Assignee: Guillaume Nodet
> Priority: Major
>
> as documented in MNG-5987 and described in MNG-5539 or MNG-6051, goals order
> in a phase can't be defined in a flexible way
> Adding a flexible mechanism would be useful
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
