Re: Consumer pom...a better name like 'public pom' ?

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

Re: Consumer pom...a better name like 'public pom' ?

Nick_S
I think the consumer POM (or maybe consumable POM) is a good name, although
I also see something in source and shared pom.

I don't think effective POM is a name for this POM. There is a name clash
with the effective POM from help:effective-pom which shows the result of
the combined POM, parent POM's and active profiles.

With regards,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Mon, Oct 7, 2019 at 8:04 AM Enrico Olivelli <[hidden email]> wrote:

> Hello,
> Robert sent out a (great) patch to introduce support for the 'consumer'
> pom,
> that is (if I understand correctly) a skinny pom that contains only useful
> information for downstream 'consumers' of the pom (poms that depend on it).
>
> This consumer pom feature is required in order to start thinking to new
> feature of the pom, because it opens the way to publishing a pom with a
> different 'version' of the original one.
>
> I feel that this name is not very clear, at least it is not clear to me.
>
> I propose these names:
> - source pom -> the source file, the pom parsed by Maven from sources
> - public pom -> the pom that is consumed by dependants, it is usually
> deployed to remote repositories....
>
> In alternative to source/public I have imagined other couples:
> - source/shared
> - original/result
> - source/result
> - source/sharable
> - source/visible
> - source/effective
> .....
>
> Thoughts ?
>
> Enrico
>
Reply | Threaded
Open this post in threaded view
|

Re: Consumer pom...a better name like 'public pom' ?

rfscholte
Hi Enrico,

As you might have noticed, I've changed the title of the related Jira  
issue. IT is now about build/consumer process. Main reason is that there's  
no consensus about the definitions of these poms yet.
The only thing that is very clear is that your local pom can change during  
install/deploy.

When we first talked about this, we only thought about distribution-part.  
The pom contains information that is only useful during build, but not  
anymore once installed/deployed.
But even for that pom there are a couple of flavors.
HervĂ© started with a wiki-page to describe all elements, and what to do  
with it.[1]
A few element can be removed without discussion: parent.relativePath and  
modules.
Also most of the build-section, but I would like to keep the packaging and  
plugins with extension. A good example to explain my reason behind this:  
it should be possible for any artifact to call dependency:unpack. Now it  
works for most common packaging types, because they are defined as part of  
Maven Core, but it doesn't belong there. Instead it should ask the plugin  
for its Unarchiver.
Some elements are required when uploading to Central, however in some  
cases these are exactly the elements you want to remove in commercial  
products.
Also, should all properties be resolved? Should all inherited elements be  
added? Should all dependencies be explicit(flattened)?

Hence, no clear definition of THE consumer pom.

Also keep in mind, that we are also thinking of a new attached file that  
is optimized for dependency resolution[2]. So maybe the distributed pom  
should stay closer to its current representation, while this new file can  
be the new definition for consumption.
But also this page is still part of discussion. For instance: the more I  
think about it, the more I would like to see a list instead of a tree, and  
a recent link[3] supported that idea.

When talking about the consumer pom, the current pom also needed to get a  
name, hence the build pom (as it is right now).
However, the improvements I made where never part of the original  
build-pom, but with the mechanism used for the "consumer-pom" I was able  
to fix some known limitations we face every day. And with this is should  
be much easier to attract users, since now they can really experience the  
changes.
But this is also a step towards model 5.0.0[4], because in the end it will  
still need a (generated) backported version to model 4.0.0, because that  
is still THE format to use in Maven repositories.

So yes, naming is very important, but then we also need to be very clear  
what is implies.

Robert

[1] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
[2]  
https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema
[3] http://eed3si9n.com/dependency-resolver-semantics
[4]  
https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0

On Mon, 07 Oct 2019 07:46:32 +0200, Enrico Olivelli <[hidden email]>  
wrote:

> Hello,
> Robert sent out a (great) patch to introduce support for the 'consumer'  
> pom,
> that is (if I understand correctly) a skinny pom that contains only  
> useful
> information for downstream 'consumers' of the pom (poms that depend on  
> it).
>
> This consumer pom feature is required in order to start thinking to new
> feature of the pom, because it opens the way to publishing a pom with a
> different 'version' of the original one.
>
> I feel that this name is not very clear, at least it is not clear to me.
>
> I propose these names:
> - source pom -> the source file, the pom parsed by Maven from sources
> - public pom -> the pom that is consumed by dependants, it is usually
> deployed to remote repositories....
>
> In alternative to source/public I have imagined other couples:
> - source/shared
> - original/result
> - source/result
> - source/sharable
> - source/visible
> - source/effective
> .....
>
> Thoughts ?
>
> Enrico

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