Re: Build vs Consumer POM study

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Tibor Digana
Is the consumer POM useful only for packaging=jar?
Because which other packagings use to have transitive dependencies as well?

On Sun, Mar 11, 2018 at 8:36 PM, Tibor Digana <[hidden email]>
wrote:

> Why the column with build POM in table does not have all items green +?
> Why there are two consumer POM's? Some is old proposal and second is yours?
> Some consumer POMs may become BOM and there I would miss
> dependencyManagement.
>
> On Sun, Mar 11, 2018 at 6:03 PM, 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]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Karl Heinz Marbaise-3
Hi Hervé,

On 11/03/18 21:05, Hervé BOUTEMY wrote:

> Le dimanche 11 mars 2018, 20:36:15 CET Tibor Digana a écrit :
>> Why the column with build POM in table does not have all items green +?
> ok, I should probably simply not have put this column: it is confusing.
> Just ignore this column
>
>> Why there are two consumer POM's? Some is old proposal and second is yours?
> thre are 2 columns for decision: the first one means it's necessary, the second
> it's just a choice
> perhaps keeping only one column with good emoticon choices would have avoided
> confusion
>
>> Some consumer POMs may become BOM and there I would miss
>> dependencyManagement.
> an example please?

a famous example are the bom's of the Spring / Spring Boot project...
these are the first which are coming into my mind...

Kind regards
Karl Heinz Marbaise

>
> Regards,
>
> Hervé
>
>>
>> On Sun, Mar 11, 2018 at 6:03 PM, 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]

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Hervé BOUTEMY
In reply to this post by Tibor Digana
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
> > [ [hidden email] (mailto:[hidden email]) ]
> >
> > On Mar 11 2018, at 10:03 am, 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]

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Chas Honton
In reply to this post by Tibor Digana
Hervé,

Great work!  Some possible additions for the wiki page:

Naming Conventions
consumer pom must continue to be named pom.xml
build pom shall be called build.xml
alternate build inputs could be build.json or build.yaml

EcoSystem Impacts
projects distributing source code through maven central should include the build pom.  This requires updating maven source plugin.
flattened consumer pom will impact version resolution; what was a deep dependency will be brought to second level
how will IDEs be affected?

> On Mar 11, 2018, at 10:03 AM, 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]
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Hervé BOUTEMY
In reply to this post by Tibor Digana
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 <[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
> >
> >> 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 <[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]