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>
