Howdy, So here is a PR for "resolver supplier" that aims to replace ServiceLocator: https://github.com/apache/maven-resolver/pull/319
This trivially simple module (new module, as to end up with complete and usable resolver, you must have some maven deps as well) provides simple and straightforward means to obtain RepositorySystem instances and customize it if needed. And there is no DI or any kind of magic included, everything is dead simple. Thanks T On Wed, Jul 26, 2023 at 10:29 AM Olivier Lamy <ol...@apache.org> wrote: > Sorry, I didn’t read the content of the issues but just saw the "get > rid..." :) > And the proposed replacement looks to be great to eventually override > some internal components. > That's Perfect!! > Thanks! > > On Wed, 26 Jul 2023 at 18:17, Tamás Cservenák <ta...@cservenak.net> wrote: > > > > Olivier, > > > > Look at related issue [1], resolver will provide a simple "static > supplier" > > (like a factory) for users as replacement. > > > > The problem with SL is that it tries to be a "poor man DI", and does it > > along the lines of old Plexus, so forces def ctor presence and is really > > just an impediment these days. Classes today in resolver behave wildly > > different when used in Maven or when in SL. > > > > [1] https://issues.apache.org/jira/browse/MRESOLVER-157 > > > > > > On Wed, Jul 26, 2023, 03:12 Olivier Lamy <ol...@apache.org> wrote: > > > > > Hi, > > > I really feel -1 regarding "Get rid of ServiceLocator in Resolver: > > > This will prevent a lot of consumers of resolver from upgrading. > > > As those consumers don't want to be forced to use all the guice stack > > > (or whatever or DI stack) and all the possible issues coming with this > > > in constrained environment/tools/librairies. > > > > > > On Thu, 20 Jul 2023 at 20:20, Tamás Cservenák <ta...@cservenak.net> > wrote: > > > > > > > > Howdy, > > > > > > > > I'd like to pitch some discussion regarding Resolver near and longer > term > > > > future. > > > > > > > > If you look at the JIRA version "planned for" 1.10.0, there are quite > > > some > > > > (even partially done) code changes that are not trivial. Moreover, we > > > want > > > > to drop some deprecated baggage as well: > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.10.0 > > > > > > > > My proposal is to move on to Resolver 2.0.0 instead. > > > > > > > > So, Resolver wise my proposal is: > > > > - resolver 1.9.x branched off, goes into "bugfix" mode > > > > - resolver master goes 2.0.0, with new features (already in JIRA or > not > > > yet) > > > > - resolver 3.0.0 will also contain java package change > > > (org.eclipse.aether > > > > -> org.apache.maven.resolver), so package change becomes "shifted" > from > > > > 2.0.0 to 3.0.0 > > > > > > > > Maven wise, this happens: > > > > - Maven 3.9.x remains on resolver 1.9.x (and will also slowly go into > > > > "bugfix" mode) > > > > - Maven 4.x moves to resolver 2.0.0 (still must support Maven 3 > plugins > > > > going directly for resolver) > > > > - Maven 5.x moves to resolver 3.0.0 (when the resolver is sealed off > > > > completely from plugins). > > > > > > > > WDYT? > > > > > > > > Thanks > > > > T > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
