very good idea such an alpha will also be the opportunity to test MNG-5001 = really check @readonly Mojo parameter, with warning instead of failure, because it seems there are unexpected side effects for example on maven-site-plugin
Regards, Hervé Le jeudi 12 novembre 2020, 20:00:21 CET Robert Scholte 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
