FWIW, I don’t think @Inject is a good replacement for @PluginFactory. @Inject is essentially the same as @Autowired. It should be placed on fields where you want the implementation to be injected. @Inject specified on a method implies that the method parameters should be injected. I don’t think that is what you are intending.
Ralph > On Oct 9, 2019, at 1:38 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Ok, but given @Scope and @Qualifier can only be used to annotate the existing > PluginElement, PluginAttribute and PluginValue annotations I am not sure what > they buy you. They can’t be used to replace the existing annotations as they > are only allowed to be used on annotation declarations. I agree that > @PluginConfiguration is somewhat redundant. All we are really doing with it > is saying that the existing Configuration object should be passed to the > method. Using @PluginConfiguration for that is easy but using @Inject as an > indicator and checking the type of the parameter could just as easily be done. > > I guess I would like to see what you think an example plugin would look like > before going further. > > Ralph > > > >> On Oct 9, 2019, at 11:46 AM, Matt Sicker <boa...@gmail.com> wrote: >> >> I want to make it simpler to write plugins. Increase testability, reuse >> more standard APIs that others would be more familiar with (easier >> onboarding), and make it simpler to implement some tangentially related >> feature ideas. >> >> As for the builder versus factory annotation, there was already special >> support for collections and maps that weren’t explicit annotations, so >> determining what to do based on the return type of the factory method was >> already an established idea. I think it made sense to combine them all into >> @PluginFactory, and because of that, I noticed the correspondence between >> that and @Inject. >> >> On Wed, Oct 9, 2019 at 13:28, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> 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> >>>> >>> >>> >>> -- >> Matt Sicker <boa...@gmail.com> > > >
