Le dimanche 11 mars 2018, 22:48:18 CET Karl Heinz Marbaise a écrit : > Hi, > > On 11/03/18 22:37, Sander Verhagen wrote: > > This is a great proposal, even in its current form. But as a long term > > Maven user, > I have a few modest questions and remarks, though. (Sorry if you didn't > mean for non-developer to chime in...) > > It's really good to hear from a Maven user. This is a public mailing > list so no limitations we are an open source project and the community > is important ...so we like to hear your ideas/opinions/questions etc... +1 particularly when it comes to such open ideas to be evaluated
> > > It would probably good to mandate some sort of <modelVersion/> still, and > > to have a hint of a strategy in place for the versioning of the two > > schemas to diverge when (not if) needed. > From my perspective and conversations with Hervé and Robert I think > it's clear to have a modelVersion for the consumer pom which in the end > is the current pom without some parts and it will keep the modelVersion > to let other tools etc. consume it correctly... yes, let's keep modelVersion: it's done in the current proposal > > > I'm a little sad that consumer POMs would be entirely flat. Isn't that a > > separate decision from having consumer POMs altogether? I feel that the > > parent hierarchy of <dependencies/> or <dependencyManagement/> may still > > be useful context when troubleshooting dependency issues involving these > > artifacts. > Hm...unsure...If we flatten that down you have a single comsumer pom > which contains all dependencies which you could analyse and download all > needed dependencies in a single go..... one interest of consumer POM is that it's simplified: do you know any user of another build tool who creates POM with parents when publishing to Central? > > > Aren't <mailingLists/> useful for end users? Or at least, some of the > > <mailingLists/> of a project? > If we are talking about the consumer pom than they make sense (for human > readers). The question is if we decide to handle it only for machine > usage or not ? we can keep mailingLists if you think it's useful: I have no strong opinion > > > Why is <profiles/> required for consumers? I'm not aware how profiles of a > > dependency ever play(ed) a role in my "dependent" project? > I can remember we had a discussion about that..my first reaction would > be saying no profiles needed in a consumer pom...but I'm not 100% > sure...we need to think that more in detail with different scenarios.. Robert has a strong opinion on this, for profiles activated by OS or JDK version, like flatten-maven-plugin Regards, Hervé > > Kind regards > Karl Heinz Marbaise > > > Sander Verhagen > > [ san...@sanderverhagen.net (mailto:san...@sanderverhagen.net) ] > > > > 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
