Great work!  Some possible additions for the wiki page:

Naming Conventions
consumer pom must continue to be named pom.xml
build pom shall be called build.xml 
alternate build inputs could be build.json or build.yaml

EcoSystem Impacts
projects distributing source code through maven central should include the 
build pom.  This requires updating maven source plugin.
flattened consumer pom will impact version resolution; what was a deep 
dependency will be brought to second level
how will IDEs be affected?

> On Mar 11, 2018, at 10:03 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> Hi,
> I wrote a Proposal in the Wiki about Build vs Consumer POM [1] and coded a 
> simplified model for the Consumer POM [2]
> As written in the proposal, this would permit us to create new POM versions 
> that change everything but not the Consumer POM part without breaking any 
> compatibility with existing Central repository users: build element is the 
> main element that could be changed, adding new build features/configuration 
> without affecting consumers.
> In addition to reviewing choices proposed for majority of POM elements, there 
> are 4 elements that require more discussion:
> - contributors
> - mailingLists
> - repositories
> - profiles/activation
> Any thoughts?
> On the code, IMHO, the only missing part is a test of flatten-maven-plugin to 
> check that everything works as expected in any situation.
> And I suppose a discussion on what we do for the xsd
> Then we should be able to use this strategy for our own artifacts, before 
> updating POM model version in any newer Maven version starting with 3.6 (yay!)
> Regards,
> Hervé
> [1] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> [2] http://maven.apache.org/studies/consumer-pom/maven-consumer.html
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to