Re: Build vs Consumer POM study

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Andreas Sewe-2
Hi,

> Naming Conventions
> consumer pom must continue to be named pom.xml
> build pom shall be called build.xml

Please don't re-use a name already occupied by another build tool (in
this case, Ant). Many IDEs associate editors based on file name and this
would confuse them. Eclipse, for example, associates "build.xml" with
its Ant Editor.

Best wishes,

Andreas


signature.asc (899 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

rfscholte
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?
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.

There is another proposal, the pdt-  or project dependency trees-file[1],  
which will the ultimate and optimized consumer-file.

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+schema


On Sun, 11 Mar 2018 18:03:07 +0100, Hervé BOUTEMY <[hidden email]>  
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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Mirko Friedenhagen-2
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 <[hidden email]> schrieb am Fr., 16. März 2018, 15:32:

> On Wed, 14 Mar 2018 23:38:41 +0100, Hervé BOUTEMY <[hidden email]>
>
> 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
> >> <[hidden email]>
> >>
> >> 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: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Jörg Schaible
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

ChrisGWarp
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 <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Mirko Friedenhagen-2
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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>