On Wed, 14 Mar 2018 23:38:41 +0100, Hervé BOUTEMY <herve.bout...@free.fr>
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
<herve.bout...@free.fr>
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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
