Hi Robert, Understood. I remember our discussion at JAlba last year about the resolution strategy options at hand.
Do you think it would be possible to expose the resolution strategy hooks in a way that may be overridden by an extension/plugin? That way alternate RS can be prototyped and tested during 4's lifespan before changing the core RS in 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:33 PM Robert Scholte <rfscho...@apache.org> wrote: > Hi Andres, > > BanDuplicatePomDependencyVersions is easy to add. IIRC now it is a > warning, I don't mind changing it to make it break the build. > > DependencyConvergence is way too difficult to achieve with the larger > projects. > > RequireUpperBoundDeps sounds reasonable as warning, although I'm sure if > the ModelValidator has enough context. > Instead I would prefer to change the resolution strategy from Nearest to > DirectOverHighest (or something similar), but that's definitely 5.0.0. > > > thanks, > Robert > On 12-11-2020 21:08:35, Andres Almiray <aalmi...@gmail.com> wrote: > 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 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 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 > > > > > > > > >
