Le jeudi 15 mars 2018, 11:18:35 CET Martijn Dashorst a écrit : > Just to throw this out there: > > The consumer POM should only contain the non-dynamic bits that can > change outside the scope of the artifacts that are described by the > POM. > > The consumer POM should consist of only the invariant parts of the > released artifacts: coordinates, dependencies, license, There should > never be a reason to modify a released POM due to a project moving > from one location to another (e.g. codehaus to github, self-hosted > build to travis, self-hosted nexus to apache). +1 on not changing a released pom but that's not a reason not to put scm location of the release in the pom: the fact that the base location can change from release to release is not an issue, it's history
> > Next to the consumer POM the Maven build should also deploy the full > POM, e.g. pom-build.xml or pom-original.xml. This allows for > researchers and others to continue to analyse the original file(s). I'm not convinced: Central contains artifacts not built with Maven, and it's not an issue to not have the build script of these artifacts > > If you're going to keep the CI, Issue tracker, etc information in the > consumer POM, why change at all? in addition to the Rationale section of https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM one additional interest is to really describe consumer features independently from build (plugins and so on), with simplified documentation Regards, Hervé > > Just my 2 cents. > > Martijn > > On Wed, Mar 14, 2018 at 11:38 PM, Hervé BOUTEMY <[email protected]> wrote: > > 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+Tree > >> s+s chema > >> > >> > >> On Sun, 11 Mar 2018 18:03:07 +0100, 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
