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 >
