Woohoo! While I'd love for Maven moving forward to 4 I was hoping to see the enforcer plugin (or at least some of its rules) baked into core, for example
BanDuplicatePomDependencyVersions DependencyConvergence RequireUpperBoundDeps I'm sure that enabling these rules by default will break thousands of builds upon upgrade, but at the very least having the behavior available with a simple turn of a switch/flag is better than having to configure the enforcer plugin by hand. I'm also aware that there are those among this group that are not fond of enforcer, so yeah. So, if this behavior can't be added to 4, at least put it in the bucket for 5 ;-) Cheers, Andres ------------------------------------------- Java Champion; Groovy Enthusiast http://andresalmiray.com http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. On Thu, Nov 12, 2020 at 9:00 PM Robert Scholte <[email protected]> wrote: > 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 > > > > >
