Le mercredi 14 mars 2018, 09:10:20 CET Robert Scholte a écrit : > 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? I don't get the intend here
> 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. what is hard here is to really define the consumer features, for example on profiles or dependencyManagement or repositories. But for the few pure descriptive fields that are discussed (like ciManagement), there is no long discussion: we'll keep them in the consumer POM, they don't really hurt common understanding > > There is another proposal, the pdt- or project dependency trees-file[1], > which will the ultimate and optimized consumer-file. yes, in the future, when consumer poms are a reality and we get all the implications, we can eventually create a completely new format, why not. IMHO, this first step of consumer vs build POM as consumer = subset of POMv4 and build POM is full POMV4 and newer is a crucial step before discussing more disruptive evolution Regards, Hervé > > 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. > > thanks, > Robert > > [1] > https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+s > chema > > > On Sun, 11 Mar 2018 18:03:07 +0100, 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
