Hello,

I do not see why profiles should be part of the consumer pom.

That would require evaluating profiles on import and I do not think this to
be a good idea.

At work I created a division pom with own lifecycles and profiles to
achieve automated packaging and upload/Maven-deploy of spring-boot jars as
Debian package and as Docker image and the pom is used directly and
indirectly as parent. Importing the spring-boot boms correctly was a
challenge of it's own because we have have non spring-boot projects as well
and aligning the dependency versions was hard.

Evaluating profiles in these boms would definitely make it even harder to
grasp why a specific version is included in the dependency tree.

By moving management and configuration of plugins to the division pom and
lifecycles, the application developer has muchless work to do.

Best regards
Mirko
-- 
Sent from my mobile

Robert Scholte <rfscho...@apache.org> schrieb am Fr., 16. März 2018, 15:32:

> On Wed, 14 Mar 2018 23:38:41 +0100, Hervé BOUTEMY <herve.bout...@free.fr>
>
> 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
>
> We must have a clear picture of the intends of the consumer pom, and to
> me
> it looks like we're mixing 2 things.
> "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"
>
> In my words: the pom.xml used in the Maven project is copied *as-is* to
> the remote repository. We cannot change the pom format on the remote
> repository side because it is used by other tools and all Maven 2.x and
> Maven 3.x. To be able to improve the pom.xml on the build side, Maven
> should be able to have a build pom, which is transformed to the
> consumer-pom during install/deploy.
>
> So far there is no word about optimization of the pom. But separation
> opens new options, we could remove parts from the consumer-pom which are
> solely interesting during builds. Hence we could decide to remove all
> (report)plugin related information.
>
> I would like to focus on the new options on the build side, while still
> using the 4.0.0 modelVersion.
> Things that come to my mind:
> - In the build pom the parent doesn't need to have a version if there is
> a
> relativePath. The transformation to the consumer pom means resolving the
> parent version based on the relativePath
> - Introduction of ${this.*}, which act like ${project.*} but will be
> replaced with the transformation to the consumer pom
> - dependencies which are part of the reactor don't need a version in the
> build pom, they will get it when transforming to the consumer pom.
>
> So this is what I mean with: is it up to Maven to decide which
> information
> should or should not be part of the consumer pom.
>
> In my opinion we should start with the separation of the poms, but should
> only the true useless information.
> The PDT file is the fully optimized file, which should reduce
> IO/networking and the memory-usage.
> As weird as it may sound, this separation of build and consumer pom even
> without touching the pom file is already a challenge, Maven Core is not
> prepared for such a change, yet.
>
> thanks,
> Robert
>
> >
> >> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Reply via email to