Le mardi 13 mars 2018, 06:11:20 CET Chas Honton a écrit : > 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. ok, now I see your concern this is done through *-source-release.zip distribution to Central, which is far more than the build descriptor And for Maven project, we check it in dist-tool source release report: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-check-source-release.html
This file is created during release through m-assembly-p in apache-release profile, configured in ASF parent: https://maven.apache.org/pom/asf/ > > For non-Apache projects it would be useful to encourage packaging all > sources sufficient to build and test the release. I don't know where to write it to have a chance for people to understand and reuse our apache-source-release-assembly-descriptor Ideas (and even patches) welcome :) > > 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. ah, if this happens, yes, we should mention. But no, it should not happen: what we flatten is *parent* content, not transitive dependencies. Then this consumer POM does not change the dependency tree AFAIK: don't hesitate to continue to challenge the solution for unexpected impacts Regards, Hervé > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
