Did we already do mvn or mvn plugins (multimodules) release with the consumer/producer pom feature? If so +1 to do a v4 with this new feature "for us" and v5 with real user features and align it with the xsd.
Le jeu. 12 nov. 2020 à 20:00, Robert Scholte <[email protected]> a écrit : > Hi, > > It is already several years ago where we started discussing about Maven > Next Generations. > Clearly we needed to work on the pom, because over time we're facing more > and more limitations. > For (Maven) Central the Model 4.0.0 will be required pom format, there's > no discussion about that. So we needed a new architecture where there's a > local pom that is transformed to Model 4.0.0 or where it can be generated. > With the implementation of MNG-6656 and the improvement with MNG-6957 > we've made the first and important steps based on pom transformation. If > this concept proofs itself, we can start thinking about enhancing the pom > model. > > When talking about Model 5.0.0 it looked like it would be great to > introduce it for Maven 5. There was even a period where we thought about > skipping Maven 4, just to sync the Model version with the Maven version. > However, we discovered that this would be a huge change, and that we would > probably need a couple of Maven 4 releases before moving to Maven 5. Maven > 4 would consist of preparation releases. > I've started writing the build/consumer to proof that the it is indeed > possible to separate the local pom from the distributed pom, even though > they both are currently still Model 4.0.0 compatible. > The original idea was: > Maven 3: build/consumer feature disabled by default > Maven 4: build/consumer feature enabled by default > > Maven 5: Model 5 > > We were worried that this wouldn't give us enough feedback. > maven-integration-testing shows that build/consumer does work. There should > be enough trust to enable it by default, it shouldn't impact existing > projects (the last find by Michael was actually great. It demonstrated the > effect when using threads. The fix made sense and Maven was stable again). > But it is simply not enough. We need much more feedback. > > Meanwhile other improvements have been done, that has impact: > - new behavior of reactor commandline arguments > - upgrade of default versions of plugins per packaging type > - requiring Java 8 > - Maven wrapper > - there's a PR waiting that will shift the logic of the > ProjectBuilder/ModelBuilder. As this is quite important for more people to > understand, I'll record a Q&A with Maarten+Martin soon and share it with > you. > There are probably more, but all these already defend my opinion about the > next Maven version. > > To me it is not a Maven 3 anymore, we're reached a point where we should > start calling it Maven 4. > The next release should probably have an alpha suffix, just to give users > the chance to do alpha testing. > > WDYT? > Robert > >
