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>
