You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mirko Friedenhagen <mf...@gmail.com> on 2018/04/16 21:46:21 UTC
Re: Build vs Consumer POM study
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 <rf...@apache.org> schrieb am Fr., 16. März 2018, 15:32:
> On Wed, 14 Mar 2018 23:38:41 +0100, Hervé BOUTEMY <he...@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
> >> <he...@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-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Build vs Consumer POM study
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Hello Chris,
I do think that a consumer pom might be a good thing. It will provide
backwards compatibility for current Maven, Gradle, sbt, kobalt etc. users
and allow to improve the model for those using future Maven versions for
building stuff.
Best regards
Mirko
--
Sent from my mobile
Chris Graham <ch...@gmail.com> schrieb am Do., 19. Apr. 2018, 12:39:
> If I've read through (and understood !!!) this thread correctly, then I'd
> like to add this:
>
> As the discussions reflect the mature (read: wierd and wonderful!) ways
> that Maven is being used, then it is looking like more and more edge cases
> are coming up (eg, profiles), and that would appear to reduce the need for
> (ie increase the complexity) a consumer pom.
>
> Personally, I am not convinced that it is a good idea. Keep the pom, work
> with what you need and ignore the bits that you don't. Only the developer
> of the module will really want to read <build> section, the rest of us
> consume it and just list it as a depency.
>
> We are adding complexity (and certainly a lot of potential confusion!), and
> adding complexity is rarely a good thing as it just tends to break more
> things.
>
>
> On Wed, Apr 18, 2018 at 3:47 AM, Jörg Schaible <jo...@gmx.de>
> wrote:
>
> > Hi Mirko,
> >
> > On Tue, 17 Apr 2018 04:44:57 +0000 Mirko Friedenhagen wrote:
> >
> > > Hello Jörg,
> > >
> > > I understand your problem, however this is quite specific. AFAIK
> > > currently profiles are *not* evaluated while resolving imported
> > > dependencies, only those inherited, so this would be a very drastic
> > > change.
> >
> > Well, the import scope is special anyway, but I agree, that dependency
> > resolution should not make a
> > difference if you use this compared to a "normal" (transitive)
> dependency.
> >
> > > For your eclipse example: maybe put OS specific stuff in modules and
> > > mark them as optional while importing?
> >
> > If SWT is not optional, your user's might be quite surprised if it had
> > been declared optional. But I do not like
> > this situation also.
> >
> > Cheers,
> > Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Build vs Consumer POM study
Posted by Chris Graham <ch...@gmail.com>.
If I've read through (and understood !!!) this thread correctly, then I'd
like to add this:
As the discussions reflect the mature (read: wierd and wonderful!) ways
that Maven is being used, then it is looking like more and more edge cases
are coming up (eg, profiles), and that would appear to reduce the need for
(ie increase the complexity) a consumer pom.
Personally, I am not convinced that it is a good idea. Keep the pom, work
with what you need and ignore the bits that you don't. Only the developer
of the module will really want to read <build> section, the rest of us
consume it and just list it as a depency.
We are adding complexity (and certainly a lot of potential confusion!), and
adding complexity is rarely a good thing as it just tends to break more
things.
On Wed, Apr 18, 2018 at 3:47 AM, Jörg Schaible <jo...@gmx.de>
wrote:
> Hi Mirko,
>
> On Tue, 17 Apr 2018 04:44:57 +0000 Mirko Friedenhagen wrote:
>
> > Hello Jörg,
> >
> > I understand your problem, however this is quite specific. AFAIK
> > currently profiles are *not* evaluated while resolving imported
> > dependencies, only those inherited, so this would be a very drastic
> > change.
>
> Well, the import scope is special anyway, but I agree, that dependency
> resolution should not make a
> difference if you use this compared to a "normal" (transitive) dependency.
>
> > For your eclipse example: maybe put OS specific stuff in modules and
> > mark them as optional while importing?
>
> If SWT is not optional, your user's might be quite surprised if it had
> been declared optional. But I do not like
> this situation also.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Build vs Consumer POM study
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Mirko,
On Tue, 17 Apr 2018 04:44:57 +0000 Mirko Friedenhagen wrote:
> Hello Jörg,
>
> I understand your problem, however this is quite specific. AFAIK
> currently profiles are *not* evaluated while resolving imported
> dependencies, only those inherited, so this would be a very drastic
> change.
Well, the import scope is special anyway, but I agree, that dependency resolution should not make a
difference if you use this compared to a "normal" (transitive) dependency.
> For your eclipse example: maybe put OS specific stuff in modules and
> mark them as optional while importing?
If SWT is not optional, your user's might be quite surprised if it had been declared optional. But I do not like
this situation also.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Build vs Consumer POM study
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Hello Jörg,
I understand your problem, however this is quite specific. AFAIK currently
profiles are *not* evaluated while resolving imported dependencies, only
those inherited, so this would be a very drastic change.
For your eclipse example: maybe put OS specific stuff in modules and mark
them as optional while importing?
Best regards
Mirko
--
Sent from my mobile
Jörg Schaible <jo...@gmx.de> schrieb am Di., 17. Apr. 2018, 00:53:
> On Mon, 16 Apr 2018 21:46:21 +0000 Mirko Friedenhagen wrote:
>
> > Hello,
> >
> > I do not see why profiles should be part of the consumer pom.
>
> If you're building a library based on SWT you have:
>
> - org.eclipse.swt:org.eclipse.swt.win32.win32.x84:3.106.0.v20170608-0516
> -
> org.eclipse.swt:org.eclipse.swt.win32.win32.x84_x64:3.106.0.v20170608-0516
> - org.eclipse.swt:org.eclipse.swt.gtk.linux.x84:3.106.0.v20170608-0516
> - org.eclipse.swt:org.eclipse.swt.gtk.linux.x84_x64:3.106.0.v20170608-0516
> - more variants for Linux and MacOS
>
> It does not matter against which SWT library you're compiling, but the
> user's of the library will require a
> different SWT library depending on their target platform. Therefore the
> library declares a dependency to
> org.eclipse.swt:org.eclipse.swt.${swt.platform}:3.106.0.v20170608-0516 and
> the property is set based on
> profiles in the project's parent.
>
> Separate artifacts of this library do not make sense, it is always the
> same save the dependency to the SWT
> library.
>
> Any solution without profiles? I don't see one and the property has to be
> kept in the customer POM also.
>
> Regards,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Build vs Consumer POM study
Posted by Jörg Schaible <jo...@gmx.de>.
On Mon, 16 Apr 2018 21:46:21 +0000 Mirko Friedenhagen wrote:
> Hello,
>
> I do not see why profiles should be part of the consumer pom.
If you're building a library based on SWT you have:
- org.eclipse.swt:org.eclipse.swt.win32.win32.x84:3.106.0.v20170608-0516
- org.eclipse.swt:org.eclipse.swt.win32.win32.x84_x64:3.106.0.v20170608-0516
- org.eclipse.swt:org.eclipse.swt.gtk.linux.x84:3.106.0.v20170608-0516
- org.eclipse.swt:org.eclipse.swt.gtk.linux.x84_x64:3.106.0.v20170608-0516
- more variants for Linux and MacOS
It does not matter against which SWT library you're compiling, but the user's of the library will require a
different SWT library depending on their target platform. Therefore the library declares a dependency to
org.eclipse.swt:org.eclipse.swt.${swt.platform}:3.106.0.v20170608-0516 and the property is set based on
profiles in the project's parent.
Separate artifacts of this library do not make sense, it is always the same save the dependency to the SWT
library.
Any solution without profiles? I don't see one and the property has to be kept in the customer POM also.
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org