Part of this is to make it simpler to access globally configured
things without having to pass around a Configuration everywhere. If
plugins can declare the explicit parts of the API they need access to
rather than the full Configuration, that should make tests a bit
lighter and easier to write.

On Wed, 9 Oct 2019 at 16:11, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
> 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>
> >
> >
> >
>
>


-- 
Matt Sicker <boa...@gmail.com>

Reply via email to