I just created a "buildconsumer" branch in Doxia [1] to have a live example of
the new simplified build POM that Maven 3.7.0 will allow [2]
As expected, this branch can't build with Maven 3.6.3, but can with Maven
3.7.0-SNAPSHOT.
And in my favorite IDE, as expected, dependency resolution does not work
because of missing info in pom.xml (which is now a build pom, with removed
tags, then was not a valid POM until now)
What is expected is IDE maintainers to check what they need to do at IDE level
to support these new POMs that only build with Maven 3.7.0-SNAPSHOT.
Regards,
Hervé
[1] https://github.com/apache/maven-doxia/tree/buildconsumer
[2]
https://github.com/apache/maven-doxia/commit/15e3de1a97bf48a394cb566783cac851c0728d98
Le samedi 4 juillet 2020, 07:35:37 CEST Jaroslav Tulach a écrit :
> Hello Robert,
> I am not sure how to deal with your announcement and given no reaction on
> the dev@netbeans mailing list, I am probably not alone. Can you formulate
> your issue as a bug report? E.g. have you tried to use your new Maven with
> NetBeans and did you face a problem? Having steps to reproduce would make
> it more real for the NetBeans community to take action.
>
> -jt
>
> po 22. 6. 2020 v 23:18 odesílatel Robert Scholte
>
> napsal:
> > 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 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.
> > - from will be removed
> > - from 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 fee
