Hi,
One of my long standing wishes
has made it to the master branch of Maven: the support for
build/consumer pom.
With this we can finally start
improving the pom without breaking the Maven eco system.
Up until now the pom.xml has
been distributed (installed/deployed) as is to both local and
remote repositories.
The good thing is that is it
fast and there is no magic.
However, it sometimes implies
adding redundant information and it also blocks any chance of
improvement for Maven
The challenge is to make it
possible to have an locally an improved "build" pom while
distributing a model 4.0.0 compatible "consumer" pom.
The whole architecture of
Maven was built upon an immutable pom.xml, so it took a while
to split this, but I managed to solve this.
And to confirm that it works,
some transformations have been added for the next
Maven release
The local pom it still model
4.0.0 compatible, but some redundant elements are not required
anymore.
-
in case the <parent/> is located at its relativePath
(default: ../pom.xml), the version can be removed. groupId
and artifactId are still required to ensure it is being
matched with the right parent.
- dependencies that are part
of the reactor don't need a version anymore
These are implemented steps to
get from the file model to the raw model, where the required
versions are added.
When distributing the pom, the
previous transformations are done, but also:
- cifriendly placeholders in
versions (${sha1}, ${revision}, ${changelist}) will be
resolved.
- <modules> from
<project> will be removed
- <relativePath> from
<parent> will be removed
These cleanups are context
aware, if they appear in some configuration, they won't be
touched.
One of our
integration-tests[1] demonstrates how new poms in a
multimodule project might look like.
Even though the latter steps
look quite small (removing elements with relative paths), it
should give us enough feedback about the whole process.
The status is that it is ready
to be embedded in supporting tools like IDEs.
We should give them time to
work on this and share feedback.
It might require some
adjustments in Maven to improve user experience.
In the meantime we need to
work on plugins that will have impact by these changes.
Most significant is are
signing maven plugins such as the maven-gpg-plugin, which
needs to work with the distributed pom instead of the local
pom.
Also all packaging plugin that
can include the pom.xml and pom.properties in their archive
should switch to the distributed pom.
The maven-shade-plugin was
marked as well, but at first glance this looks fine.
In the end all our plugins
must be verified, just to be sure.
So there's enough to work on.
In general I avoid giving
timelines about how fast a new release will be available.
Due to the overhead, the small
amount of available time of the few volunteers working on
Maven, I prefer to have a worth set of changes.
In this case the impact of the
changes can be huge, and I want to have enough faith that we
won't introduce irreversible mistakes.
Don't expect a new official
release in the 3 next months, however we might have alpha or
beta releases.
There is a wiki page that
explains this topic in more detail[2]
It is still a draft, as there
are still parts where we need to reach consensus.
This page is intended as a
base for discussions by Maven developers, users and related
projects, such as IDEs, Repository Managers, CI Servers, etc.
Looking forward for any
feedback,
Robert Scholte
Apache Maven project