Re: Build vs Consumer POM study

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

Re: Build vs Consumer POM study

Tibor Digana
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

Hervé BOUTEMY
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?

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]



---------------------------------------------------------------------
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, 20:40:39 CET Tibor Digana a écrit :
> Is the consumer POM useful only for packaging=jar?
no, it's useful for any packaging not =pom

> Because which other packagings use to have transitive dependencies as well?
remember: consumer POM is just an explicit reduction of current POM when you
don't build with it but just consume it
Then transitive dependency management is here, not an option

Regards,

Hervé

>
> 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]



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

Sander Verhagen
In reply to this post by Tibor Digana
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 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.
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.
Aren't <mailingLists/> useful for end users? Or at least, some of the <mailingLists/> of a project?
Why is <profiles/> required for consumers? I'm not aware how profiles of a dependency ever play(ed) a role in my "dependent" project?

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]
>

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 mardi 13 mars 2018, 06:11:20 CET Chas Honton a écrit :
> Re: updating source plugin -
>
> For Apache projects, all sources required to build and test the release must
> be part of the distribution. It would be useful to any Apache project that
> desires to build a release through the source plugin to have the build pom
> automatically packaged.
ok, now I see your concern
this is done through *-source-release.zip distribution to Central, which is far more than the build descriptor
And for Maven project, we check it in dist-tool source release report:
https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-check-source-release.html

This file is created during release through m-assembly-p in apache-release profile, configured in ASF parent:
https://maven.apache.org/pom/asf/

>
> For non-Apache projects it would be useful to encourage packaging all
> sources sufficient to build and test the release.
I don't know where to write it to have a chance for people to understand and reuse our apache-source-release-assembly-descriptor
Ideas (and even patches) welcome :)

>
> Re: impacting dependency version resolution -
> When multiple version are defined for the same artifact in the dependency
> tree, the nearest definition determines the version. I can imagine
> scenarios where flattening the consumer pom will change which definition is
> nearest, and therefore the version may change.  This is a corner case, but
> should be mentioned.
ah, if this happens, yes, we should mention.
But no, it should not happen: what we flatten is *parent* content, not  transitive dependencies.
Then this consumer POM does not change the dependency tree AFAIK: don't hesitate to continue to challenge the solution for unexpected impacts

Regards,

Hervé

>
>
> Chas
>
> > On Mar 12, 2018, at 4:13 PM, Hervé BOUTEMY <[hidden email]> wrote:
> >
> > Hi Charles,
> >
> > Thanks for the feedback
> >
> > Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit :
> >> Hervé,
> >>
> >> Great work!
> >
> > Thank you: it took a lot of time and discussion :)
> >
> >> 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
> >
> > ok, makes sense, I reworked it and added to the proposal
> >
> >> EcoSystem Impacts
> >> projects distributing source code through maven central should include
> >> the
> >> build pom. This requires updating maven source plugin.
> >
> > why? do people building with Ant publish their build.xml?
> >
> >> flattened consumer
> >> pom will impact version resolution;
> >
> > no, the intent is that it does absolutely not change anything at that
> > level: that's the whole idea, for compatibility
> >
> >> what was a deep dependency will be
> >> brought to second level how will IDEs be affected?
> >
> > ??
> >
> > Regards,
> >
> > Hervé
> >
> >>> 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]



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

rfscholte
In reply to this post by Tibor Digana
On Tue, 13 Mar 2018 00:13:59 +0100, Hervé BOUTEMY <[hidden email]>  
wrote:

> Hi Charles,
>
> Thanks for the feedback
>
> Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit :
>> Hervé,
>>
>> Great work!
> Thank you: it took a lot of time and discussion :)
>
>> 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
> ok, makes sense, I reworked it and added to the proposal

Well, I think renaming would cause IDE issues (it's claimed for Ant  
projects), and this file still represents the Project Object Model, hence  
pom still makes sense.
I expect more issues than benefits, and everywhere is documented: a Maven  
project requires a pom.xml

>
>>
>> EcoSystem Impacts
>> projects distributing source code through maven central should include  
>> the
>> build pom. This requires updating maven source plugin.
> why? do people building with Ant publish their build.xml?
>
>>  flattened consumer
>> pom will impact version resolution;
> no, the intent is that it does absolutely not change anything at that  
> level:
> that's the whole idea, for compatibility
>
>> what was a deep dependency will be
>> brought to second level how will IDEs be affected?
> ??
>
> Regards,
>
> Hervé
>
>>
>> > 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

michaelo
Am 2018-03-13 um 18:23 schrieb Robert Scholte:

> On Tue, 13 Mar 2018 00:13:59 +0100, Hervé BOUTEMY
> <[hidden email]> wrote:
>
>> Hi Charles,
>>
>> Thanks for the feedback
>>
>> Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit :
>>> Hervé,
>>>
>>> Great work!
>> Thank you: it took a lot of time and discussion :)
>>
>>> 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
>> ok, makes sense, I reworked it and added to the proposal
>
> Well, I think renaming would cause IDE issues (it's claimed for Ant
> projects), and this file still represents the Project Object Model,
> hence pom still makes sense.
> I expect more issues than benefits, and everywhere is documented: a
> Maven project requires a pom.xml

I fully agree, build.xml is already taken. Let's stick to pom.xml or at
least to pom-consumer.xml.

Michael


---------------------------------------------------------------------
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
I don't see any issues with content provided: org.springframework.boot:spring-
boot-dependencies has a "pom" packaging, then would be deployed directly as
build POM, containing dependencyManagement

Regards,

Hervé


Le mardi 13 mars 2018, 12:25:21 CET Arnaud Héritier a écrit :

> Spring Boot (but others are doing too) is using a lot the dependencies with
> ~empty jar artifacts (
> http://repo.maven.apache.org/maven2/org/springframework/boot/spring-boot-sta
> rter-web/2.0.0.RELEASE/ )
>
> You declare something like :
>
> <dependencyManagement>
>   <dependencies>
>     <dependency>
>       <groupId>org.springframework.boot</groupId>
>       <artifactId>spring-boot-dependencies</artifactId>
>       <version>${spring-boot.version}</version>
>       <type>pom</type>
>       <scope>import</scope>
>     </dependency>
>   </dependencies>
> </dependencyManagement>
>
>   <dependencies>
>     <dependency>
>       <groupId>org.springframework.boot</groupId>
>       <artifactId>spring-boot-starter-web</artifactId>
>     </dependency>
> ....
>
> and you have everything to develop your web front-end
>
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-proje
> ct/spring-boot-starters/spring-boot-starter-web/pom.xml
>
> This is contrary to the maven philosophy where you should explicitely
> declare every artifact you are using to avoid the surprise of a dependency
> change which removes / modifies some of them but it has the advantage to
> keep your pom readable and the dependencies under control (of the
> framework)
>
> The mega BOM is here :
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-proje
> ct/spring-boot-dependencies/pom.xml
>
> And it imports some others boms
>
>
> On Mon, Mar 12, 2018 at 1:05 AM, Hervé BOUTEMY <[hidden email]>
>
> wrote:
> > Le dimanche 11 mars 2018, 21:14:16 CET Karl Heinz Marbaise a écrit :
> > > 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...
> >
> > coordinates please
> >
> > Regards,
> >
> > Hervé
> >
> > > 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]
> >
> > ---------------------------------------------------------------------
> > 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

Hervé BOUTEMY
In reply to this post by Tibor Digana
Le mardi 13 mars 2018, 21:59:56 CET Andreas Sewe a écrit :

> Hi,
>
> as a user of Maven and a researcher analyzing what's in Maven central, I
> would prefer to see
>
>   <ciManagement>
>
> in the "kept by choice" category as well. While <issueManagement> may be
> more useful for end-user facing tools, in this day and age of badges
> pointing to CI servers on Github, I can still see this as useful for
> consuming tools (or just researchers gathering statistics ;-)
ok, why not
I'll change

>
> As for
>
>   <distributionManagement>
>
> I agree with removing
> distributionManagement/(repositories|snapshotRepositories) from the
> consumer POM, but am left wondering about
> distributionManagement/downloadUrl. Alas, from the documentation [1] I
>
> don't quite understand, what downloadUrl means:
> > is the url of the repository from whence another POM may point to in order
> > to grab this POM's artifact. In the simplest terms, we told the POM how
> > to upload it (through repository/url), but from where can the public
> > download it? This element answers that question.
> But <downloadElement> seems to be directed at "the public" somehow, so
> it may be a candidate for the consumer POM.
POM reference is a lot more clear
http://maven.apache.org/ref/3.5.3/maven-model/maven.html#class_distributionManagement

then I find it a good idea: I'll add this field

Regards,

Hervé

>
> Hope this helps.
>
> Andreas
>
> [1] <http://maven.apache.org/pom.html#Distribution_Management>



---------------------------------------------------------------------
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 michaelo
Le mardi 13 mars 2018, 22:47:50 CET Michael Osipov a écrit :

> Am 2018-03-13 um 18:23 schrieb Robert Scholte:
> > On Tue, 13 Mar 2018 00:13:59 +0100, Hervé BOUTEMY
> >
> > <[hidden email]> wrote:
> >> Hi Charles,
> >>
> >> Thanks for the feedback
> >>
> >> Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit :
> >>> Hervé,
> >>>
> >>> Great work!
> >>
> >> Thank you: it took a lot of time and discussion :)
> >>
> >>> 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
> >>
> >> ok, makes sense, I reworked it and added to the proposal
> >
> > Well, I think renaming would cause IDE issues (it's claimed for Ant
> > projects), and this file still represents the Project Object Model,
> > hence pom still makes sense.
> > I expect more issues than benefits, and everywhere is documented: a
> > Maven project requires a pom.xml
>
> I fully agree, build.xml is already taken. Let's stick to pom.xml or at
> least to pom-consumer.xml.
pom-consumer.xml does not have any use case: you never maintain it as a file in
your scm
The only question is for pom.xml.
And the more I think at it, the more I don't see really what we would win in
changing the pom.xml file name (in scm, since in Maven repository this file is
renamed)

Regards,

Hervé

>
> Michael
>
>
> ---------------------------------------------------------------------
> 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

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
Le mercredi 14 mars 2018, 01:37:38 CET Laird Nelson a écrit :

> On Tue, Mar 13, 2018 at 5:34 PM Hervé BOUTEMY <[hidden email]> wrote:
> > I don't see any issues with content provided:
> > org.springframework.boot:spring-
> > boot-dependencies has a "pom" packaging, then would be deployed directly
> > as
> > build POM, containing dependencyManagement
>
> I'm not sure, but I think the question is: when you use this Spring Boot
> pom.xml not just in import scope (as a BOM) but in compile scope as well
> (so you "use" its transitive dependencies in compile scope), are its
> dependencies present in your project's consumer pom.xml under this proposal?
the answer has 2 parts:
1. no, what is flattened is parent configuration, not transitive dependencies
2. AFAIK, using these coordinates as compile dependency does not have any
interest: the pom only contains dependencyManagement but no dependency, then
it won't change anything on transitive resolution

>
> My apologies if I've misunderstood the issue.
it's not so easy to understand each other: and this discussion proves we mix
build features with resolution features for too much time
it's time to better define everything

Regards,

Hervé

>
> Best,
> Laird



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

Martijn Dashorst
In reply to this post by Tibor Digana
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).

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).

If you're going to keep the CI, Issue tracker, etc information in the
consumer POM, why change at all?

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



--
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

Lennart Jörelid
In reply to this post by Tibor Digana
Hello all,

As you have reflected on earlier, it is possible although somewhat clunky
to implement the Consumer vs Build POM today using the Maven Enforcer and a
custom rule to identify the two types of POM. I have done one such
implementation (found at GitHub
<https://github.com/lennartj/nazgul_tools/blob/master/codestyle/src/main/java/se/jguru/nazgul/tools/codestyle/enforcer/rules/ProjectType.java>)
which has been used in a lot of projects for about 10 years now, and is
based on some simple rules for [GroupID-ArtifactID-Packaging]. The
implementation provides such rules to identify project stereotypes of
different kinds, to enable applying different rules to different projects.
With a simple piece of logic, one can parse and match the respective values
within the POM to find out the type of project currently being built.

In the POM case, I simply called the stereotypes REACTOR and PARENT, since
one is used to construct the Maven reactor and one is used as parent for
other projects.

/**
 * <p>Reactor project, of type pom. May not contain anything except
module definitions.</p>
 */
REACTOR(".*-reactor$", null, "pom"),

/**
 * <p>Parent pom project, of type pom, defining dependencies and/or build
 * life cycles. May not contain module definitions.</p>
 */
PARENT(".*-parent$", null, "pom"),


I basically needed some simple way to promote code health in refactoring
big enterprise codebases. It has worked well - so I'd say dividing the
currently somewhat overloaded POM into those 2 stereotypes is a good thing.
However, as people know that the Maven Way (tm) tends to be a successful
way to use Maven, I think we need to complement the documentation with some
pointers to "how you can structure your codebase" examples or
documentation.
I am certain there are quite a few out there in addition to the Nazgul
Tools Codestyle <https://github.com/lennartj/nazgul_tools>.

Fair?


2018-03-14 23:45 GMT+01:00 Hervé BOUTEMY <[hidden email]>:

> IMHO, in this case, the dependency should be defined in the profile in the
> consumer POM, with resolved property of the profile.
>
> I don't know if flatten-maven-plugin currently detects such a situation
> and is
> able to move the parametrized dependency in main section to
> non-parametrized
> dependency in profile. Or at least detect that the situation is complex and
> require some tricks.
>
> This situation won't happen often, but sure, this will happen and we need
> to
> define what to do.
>
> Currently, the study in Git did not try to dig into implementation of the
> transformation: but this edge case will be a good one to test.
>
> Regards,
>
> Hervé
>
> Le mercredi 14 mars 2018, 13:21:21 CET Jörg Schaible a écrit :
> > Am Mon, 12 Mar 2018 01:12:52 +0100 schrieb Hervé BOUTEMY:
> >
> > [snip]
> >
> > >> > 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
> >
> > How would you solve this case then:
> >
> > Somewhere in a parent pom:
> > ============== %< =============
> >   <profile>
> >     <id>linux-amd64</id>
> >     <activation>
> >       <os>
> >       <family>linux</family>
> >       <arch>amd64</arch>
> >       </os>
> >     </activation>
> >     <properties>
> >       <swt.artifactId>org.eclipse.swt.gtk.linux.x86_64</swt.artifactId>
> >     </properties>
> >   </profile>
> >   <profile>
> >     <id>windows-amd64</id>
> >     <activation>
> >       <os>
> >         <family>windows</family>
> >         <arch>amd64</arch>
> >       </os>
> >     </activation>
> >     <properties>
> >       <swt.artifactId>org.eclipse.swt.win32.win32.x86_64</swt.art
> ifactId>
> >     </properties>
> >   </profile>
> >   <!-- following more variants for supported platforms -->
> > ============== %< =============
> >
> > Somewhere in a child project X:
> >
> > ============== %< =============
> >   <dependencies>
> >     <dependency>
> >       <groupId>org.eclipse.swt</groupId>
> >       <artifactId>${swt.artifactId}</artifactId>
> >       <version>3.106.0.v20170608-0516</version>
> >     </dependency>
> >   </dependencies>
> > ============== %< =============
> >
> > What would a consumer-pom.xml of X look like and how can a client of X
> > still depend on the proper dependency for its target platform?
> >
> > Cheers,
> > Jörg
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>


--

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+