maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <>
Subject Re: Build vs Consumer POM study
Date Wed, 14 Mar 2018 08:10:20 GMT
The more I think about this, the more I believe we should approach this a  
little bit different.

There are discussions which parts should be part and which shouldn't. But  
is this up to us/Maven?
How about removing those bits that are useless, i.e build and reporting  
and I tend to agree on distributionmanagement. These are all instructions  
specifically for building, reporting and its distribution and does not add  
value once deployed.
If there are additional elements that users want to remove, they can  
decide to use the flatten-maven-plugin.

There is another proposal, the pdt-  or project dependency trees-file[1],  
which will the ultimate and optimized consumer-file.

I also have demands about the implementation, but I'll put that in a  
separate mail. It requires a detailed story and maybe some drawings to  
fully understyand it.



On Sun, 11 Mar 2018 18:03:07 +0100, Hervé BOUTEMY <>  

> 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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message