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?d...@netbeans.apache.org:lte=1M:consumer On 4-7-2020 07:35:59, Jaroslav Tulach <jaroslav.tul...@gmail.com> 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
