cstamas commented on PR #13259: URL: https://github.com/apache/maven/pull/13259#issuecomment-5818879298
@fridrich Thanks for working on this! I agree with your assessment, in fact, today I see as wrong decision of mine, when I placed "suppliers" into Resolver, they should go into Maven (as they are Maven version specific) in fact. Longer story: supplier module was introduced in 1.9 (where ServiceLocator still exists), to provide simple transitioning for users of ServiceLocator, as explained on page https://maven.apache.org/resolver/third-party-integrations.html But today, for Resolver 2.x things got more complicated, and Resolver 2.x offering "mvn3 supplier" -- that is using 3.9.x classes makes things brrrr. I would really like to see some cleanup and sanitization in this area. Ideally, maven-resolver (sans "demos", that are one plugin and some code that demonstrate "live resolver", there Maven classes are must) should not depend on Maven, and ideally maven-resolver-provider (with resolver JARs on classpath) should be able to bring up usable Resolver instance (object graph, either via Sisu or "manually" like suppliers did). And ideally, this should be sorted before 3.10 goes out. All in all, maven-resolver-provider pull in supplier was a bad decision. Maybe just copy-pasta the classes from supplier? Note: when reverting/undoing 27f7b546886b9d8fd6c7695523bb544db9eeed26 the "ADR decorator" should survive! edit: created "counter PR" that I think is really what we want: https://github.com/apache/maven/pull/13266 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
