I don’t understand. You can’t add javax.inject stuff into our namespace without changing the package name. And if you change the package name I don’t see any benefit at all as the current names are much clearer.
I have no problem with Configurations being a plugin except it will currently cause an endless loop as plugins are captured during configuration. So any change you make here is going to be huge. Ralph > On Oct 8, 2019, at 2:23 PM, Matt Sicker <boa...@gmail.com> wrote: > > I'm thinking that the old annotations can be supported in terms of the > javax.inject API. As for requiring a jar, that's why I've also > suggested just adopting the annotations into our own package > somewhere. > > Either way this is done, my general goal is to untangle other areas in > the core API that could benefit from generic DI support. See for > example turning Configuration into a plugin. > > On Tue, 8 Oct 2019 at 15:40, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> I don’t see how that relates. The proposal as I understand it is to replace >> the existing annotations with annotations from javax.inject, which would >> require a JEE jar. >> >> Ralph >> >>> On Oct 8, 2019, at 1:31 PM, Jochen Wiedmann <jochen.wiedm...@gmail.com> >>> wrote: >>> >>> On Tue, Oct 8, 2019 at 10:26 PM Ralph Goers <ralph.go...@dslextreme.com> >>> wrote: >>>> >>>> IIUC this will require a dependency on a Java EE jar? For that reason >>>> alone, no. >>> >>> Don't think so. A simple (mostly JSR 330 compliant) provider can be >>> implemented in a few classes: >>> >>> https://github.com/jochenw/afw/tree/master/afw-core/src/main/java/com/github/jochenw/afw/core/inject/simple >>> >> >> > > > -- > Matt Sicker <boa...@gmail.com> >
