Hervé, 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 > >
