I still don’t understand what the benefit is. IIUC your plan is to add the @Scope and @Qualifier annotations to the @PluginElement and @PluginAttribute. If that somehow helps, great, as it is will be invisible to plugin developers.
One thing I find odd is that Builders were annotated with @PluginBuilderFactory and are now annotated with @PluginFactory. Previously, only factory methods were annotated with @PluginFactory. What is odd is that the methods previously annotated with @PluginBuilderFactory create a Builder. They builder then creates the plugin object. However the methods annotated with @PluginFactory directly created the plugin object. Now you have both annotated with @PluginFactory, which means some methods behave one way and others behave another way. How is that clearer? That said changing both to @Inject has some merit although I am not sure how you are determining that one is creating a Builder that then creates the object vs a method that creates the object. But again, what problem is this trying to solve? How will this make things easier for users? Ralph > On Oct 9, 2019, at 10:42 AM, Matt Sicker <boa...@gmail.com> wrote: > > To clarify on the mapping between javax.inject and the existing > annotations, I believe this would work: > > @PluginFactory can be replaced by @Inject > @PluginElement is a @Scope annotation > @PluginAttribute is a @Qualifier annotation > @PluginConfiguration could be a scope or singleton, but it's redundant > @PluginNode could be a scope, but it's somewhat redundant > @PluginValue would be a @Qualifier > > On Wed, 9 Oct 2019 at 10:05, Matt Sicker <boa...@gmail.com> wrote: >> >> 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> > > > > -- > Matt Sicker <boa...@gmail.com> >
