Re: [DISCUSS] Maven Resolver future

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

Re: [DISCUSS] Maven Resolver future

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 wrote: > > Olivier, > > Look at related issue

Re: [DISCUSS] Maven Resolver future

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

Re: [DISCUSS] Maven Resolver future

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

Re: [DISCUSS] Maven Resolver future

Ok, makes sense if we don't re-break the API just after (previous point) otherwise I would skip the removal to do both in next major then. Just my 2cts indeed. Romain Manni-Bucau @rmannibucau | Blog | Old Blog

Re: [DISCUSS] Maven Resolver future

meh, auto correct: IS AT THE COST ("not" should be removed). So in other words, session and some other components will get some deprecated methods (were deprecated for 2 years) removed. T On Tue, Jul 25, 2023 at 4:55 PM Tamás Cservenák wrote: > Howdy, > > Just a remark, that may not be clear

Re: [DISCUSS] Maven Resolver future

Howdy, Just a remark, that may not be clear from the thread starter: "dropping deprecated baggage" is not at the cost of binary breakage, hence I assumed 2.0 is good to make it clear. (binary breakage in form that methods and classes deprecated since version 1.8.0 will be dropped) T On Tue, Jul

Re: [DISCUSS] Maven Resolver future

Nothing strong against, just noting that 2.x does not plan anything requiring to upgrade (1.9.x is fine for the planned changes) so I'd say your 3 can be the 2 and hopefully we can move to a more reactive version (would enable to not set up aether with 128 threads or alike on CI but just 4 and

Re: [DISCUSS] Maven Resolver future

Tangential note: I dislike multi-digiti minor versions. 1.10 is just way too easy to confuse with 1.1.0. That is, when one reaches 1.9 it's time to move to 2.0, even if you don't plan to break the API in any way. So +1 for moving the next version to 2.0 On Thu, Jul 20, 2023 at 6:20 AM Tamás

Re: [DISCUSS] Maven Resolver future

ping On Thu, Jul 20, 2023 at 12:19 PM Tamás Cservenák 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.

[DISCUSS] Maven Resolver future

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: