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 <[email protected]> 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 <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
