Re: Maven moving to the next level: the build/consumer pom

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

Re: Maven moving to the next level: the build/consumer pom

rfscholte
Hello Jaroslav,

I might have missed the message on the dev@netbeans mailinglist. Based on the responses in ponymail[1] I think I've answered them all (I don't know which one came from netbeans).
I haven't tried it with any IDE, my main goal is that Maven itself keeps working as expected and I've found some edge cases that need improvement.
This pre-announcement was intended as a reach out, so hopefully nobody would be surprised once these features are in the next release of Maven.
In this case I added explicitly 4 buildtools (I had bcc-ed private jetbrains adresses), but there are more. 
I don't know if and how every change might impact every IDE, hence I'll announce such using the available maven mailinglists.
If there is a need for an explicit mailinglist regarding these topics, let me know.

thanks,
Robert

[1] https://lists.apache.org/list.html?dev@...:lte=1M:consumer

On 4-7-2020 07:35:59, Jaroslav Tulach <[hidden email]> wrote:
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 feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Reply | Threaded
Open this post in threaded view
|

Re: Maven moving to the next level: the build/consumer pom

Mark Derricutt
Hervé,

If you configure IntelliJ (projecting much Mark?) to use Maven
3.7.0-SNAPSHOT as it’s maven version, does that work?

I tend to configure my IJ to use my built SNAPSHOT when testing out Maven
releases.

Mark

On 6 July 2020 at 8:21:57 PM, Hervé BOUTEMY ([hidden email]) wrote:

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.