I was ok w it either way but I do understand Ralph's POV. So maybe leave 2.x alone in this department, unless there is an issue this would solve that I missed.
Gary On Sat, Apr 16, 2022, 18:04 Ralph Goers <ralph.go...@dslextreme.com> wrote: > The question isn’t can it be. The question is, should it be. At this point > I don’t see why it should. It is necessary in 3.0 to accomplish some of the > things we want to do there. But at this point I don’t think we should be > doing major things to 2.x. > > Ralph > > > On Apr 16, 2022, at 11:31 PM, Matt Sicker <boa...@gmail.com> wrote: > > > > Features only available in DI have been asked about in a couple > different situations already in 2.x development. I don’t plan on porting > _all_ the changes I made in 3.x (such as the various startup optimizations, > removal of deprecated code, and making all the existing system property > based classes injectable), though I was hoping to at least enable some of > the DI functionality for 2.18.0 as it should also make it a little easier > to continue maintaining 2.x once we start making 3.x releases. > > > > I’ll open a PR with the general core of what I can port over without the > deeper refactoring that was done in 3.x. Most of the relevant code here can > be copied directly from master into this branch along with some updates to > AbstractConfiguration. > > — > > Matt Sicker > > > >> On Apr 16, 2022, at 15:20, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> > >> A) Why? > >> B) I am not really a fan of this. I’d prefer to leave this major of a > change for 3.0 unless there is a very compelling reason to do it sooner. > I’d prefer to focus on getting 3.0 out sooner. > >> > >> Ralph > >> > >>> On Apr 16, 2022, at 7:14 PM, Matt Sicker <boa...@gmail.com> wrote: > >>> > >>> Hey all, I’m considering porting the new DI system back to 2.x (but > put all in core as there’s no plugins module there) as there seems to be > interest in using this earlier than in 3.0. While I’d be willing to do > this, I wanted to see what anyone else thinks about the idea. I’d likely > begin on a branch or fork, so it’d be nice to get another 2.17.x release > out before I merged anything about this. > >>> > >>> Only real disadvantage of doing this is that the packages move around > a little in 3.x, so I’ll have to add more duplicate annotations in 3.x > afterwards to maintain compatibility. Although maybe I can start using the > plugins package inside core in 2.x so it’s the same package name as in 3.x. > >>> > >>> — > >>> Matt Sicker > >> > > > >
