Hmm, if it does not work e2e then even an alpha is pointless cause nobody can test it further than a hello world, was my point.
Le jeu. 12 nov. 2020 à 21:01, Robert Scholte <[email protected]> a écrit : > I don't expect that signing will work with the the first alpha, but that > shouldn't stop us of collecting feedback. > Also we need to have a look at all plugins that do something with the pom, > like every packaging plugin, maven-source-plugin, maven-release-plugin to > ensure the "right" pom is added. > > And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even > though they are stable). > There's still enough work to reach 4.0.0, but most likely the first alphas > are already good enough for the majority. > > On 12-11-2020 20:45:09, Romain Manni-Bucau <[email protected]> wrote: > 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 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 > > > > >
