Ok, I see the issue. I won’t add a dependency on the API. I do want to try refactoring the 3.x API to use an annotation model similar to that. I’ll show a proof of concept sometime soon.
On Tue, Oct 8, 2019 at 18:50, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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> > > > > > -- Matt Sicker <boa...@gmail.com>
