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 <eolive...@gmail.com>
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
