This is a great proposal, even in its current form. But as a long term Maven 
user, I have a few modest questions and remarks, though. (Sorry if you didn't 
mean for non-developer to chime in...)

It would probably good to mandate some sort of <modelVersion/> still, and to 
have a hint of a strategy in place for the versioning of the two schemas to 
diverge when (not if) needed.
I'm a little sad that consumer POMs would be entirely flat. Isn't that a 
separate decision from having consumer POMs altogether? I feel that the parent 
hierarchy of <dependencies/> or <dependencyManagement/> may still be useful 
context when troubleshooting dependency issues involving these artifacts.
Aren't <mailingLists/> useful for end users? Or at least, some of the 
<mailingLists/> of a project?
Why is <profiles/> required for consumers? I'm not aware how profiles of a 
dependency ever play(ed) a role in my "dependent" project?

Sander Verhagen
[ ( ]

On Mar 11 2018, at 10:03 am, Hervé BOUTEMY <> 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]
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Reply via email to