Build vs Consumer POM study

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

Build vs Consumer POM study

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

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


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


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

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

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

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]

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

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

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

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Chas Honton
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.

For non-Apache projects it would be useful to encourage packaging all sources sufficient to build and test the release.

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.


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]

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Arnaud Héritier
In reply to this post by Hervé BOUTEMY
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-starter-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-project/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-project/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]
>
>


--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Andreas Sewe-2
In reply to this post by Hervé BOUTEMY
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 ;-)

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.

Hope this helps.

Andreas

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


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

Re: Build vs Consumer POM study

ljnelson
In reply to this post by Arnaud Héritier
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?

My apologies if I've misunderstood the issue.

Best,
Laird
Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Jörg Schaible-5
In reply to this post by Karl Heinz Marbaise-3
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.artifactId>
    </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]

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

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Hervé BOUTEMY
In reply to this post by Jörg Schaible-5
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.artifactId>
>     </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]

Reply | Threaded
Open this post in threaded view
|

Re: Build vs Consumer POM study

Robert Scholte-8
In reply to this post by Hervé BOUTEMY
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
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: [hidden email]
For additional commands, e-mail: [hidden email]