Re: updating source plugin -

For Apache projects, all sources required to build and test the release must be 
part of the distribution. It would be useful to any Apache project that desires 
to build a release through the source plugin to have the build pom 
automatically packaged. 

For non-Apache projects it would be useful to encourage packaging all sources 
sufficient to build and test the release. 

Re: impacting dependency version resolution -
When multiple version are defined for the same artifact in the dependency tree, 
the nearest definition determines the version. I can imagine scenarios where 
flattening the consumer pom will change which definition is nearest, and 
therefore the version may change.  This is a corner case, but should be 
mentioned. 


Chas

> On Mar 12, 2018, at 4:13 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> Hi Charles,
> 
> Thanks for the feedback
> 
> Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit :
>> Hervé,
>> 
>> Great work!
> Thank you: it took a lot of time and discussion :)
> 
>> 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
> ok, makes sense, I reworked it and added to the proposal
> 
>> 
>> EcoSystem Impacts
>> projects distributing source code through maven central should include the
>> build pom. This requires updating maven source plugin.
> why? do people building with Ant publish their build.xml?
> 
>> flattened consumer
>> pom will impact version resolution;
> no, the intent is that it does absolutely not change anything at that level: 
> that's the whole idea, for compatibility
> 
>> what was a deep dependency will be
>> brought to second level how will IDEs be affected?
> ??
> 
> Regards,
> 
> Hervé
> 
>> 
>>> 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
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to