I will note that theoretically, there may be differences in how default values are handled if you use @PluginAttribute on a builder attribute, but I think it'd only be the case if you specify a default value in both the annotation and the field.
On Thu, 16 Jan 2020 at 10:48, Matt Sicker <[email protected]> wrote: > > Yeah, I'm still working on some fundamental changes to annotations, > but it will still be backward compatible with what already worked > before. You can use @PluginAttribute directly on either the fields of > the builder class or the setter methods (I forget if that's supported > in 2.x, but it works in master right now). I had originally introduced > the @PluginBuilderAttribute annotation because pre-Java 8, we could > not reflect on the parameter name of a method, so providing a separate > annotation with a default string for "use reflection to get the name" > was done. After Java 8, we were able to merge that default naming > strategy functionality into @PluginAttribute which removes the need > for having two annotations. > > Similarly, I merged @PluginFactory and @PluginBuilderFactory in > master, though I've been struggling with that a little bit in my new > DI system as the two factories are logically different types (one is > essentially a static @Produces method a la CDI while the other > produces a partially-initialized bean which doesn't have a direct > analogue in CDI). > > And yes, there will be extensive documentation updates about this when > I'm ready to integrate into master. One of the major goals of this > mini DI system is to make it simpler for plugin authors to write and > test plugins. For example, this would allow for a more generic global > singleton configuration bean like with Jackson's ObjectMapper and > other classes that we currently rely on system properties for > inversion of control. > > So, if you're working on maintaining 2.x and 3.x compatibility, just > use the @PluginBuilderFoo annotations from 2.x; they're not going > anywhere! > > On Thu, 16 Jan 2020 at 10:30, Ralph Goers <[email protected]> wrote: > > > > I think Matt is still figuring out how he wants to change things. I imagine > > he will document it after he has finished. > > > > These changes should only be in master. > > > > Ralph > > > > > On Jan 16, 2020, at 8:57 AM, Carter Kozak <[email protected]> wrote: > > > > > > Perhaps we need to update our docs/javadoc. > > > > > > -ck > > > > > >> On Jan 16, 2020, at 10:54 AM, Ralph Goers <[email protected]> > > >> wrote: > > >> > > >> Builders haven’t gone away, if that is what you are thinking. I think > > >> all Matt did was make it so you could use @PluginAttribute wherever you > > >> would have used @PluginBuilderAttribute. I am not really sure why. > > >> Nothing else should have changed. > > >> > > >> Ralph > > >> > > >>> On Jan 16, 2020, at 8:35 AM, Volkan Yazıcı <[email protected]> > > >>> wrote: > > >>> > > >>> Hello, > > >>> > > >>> Started working on replacing JsonLayout with LogstashLayout. I have > > >>> noticed that @PluginAttributeBuilder is deprecated in favor of > > >>> @PluginAttribute. I am not equipped with the sufficient background on > > >>> this decision's justification, but what I can tell is I find > > >>> @PluginAttribute unpleasant to work with due to following reasons: > > >>> > > >>> - Now I have a ctor with dozens of parameters that *must* be passed in > > >>> tests. Builders were indicating the context as well: > > >>> builder.setFooEnabled(true).setBarEnabled(false). Now that is all > > >>> gone: new FooLayout(..., true, true, false, false, true, ...). > > >>> > > >>> - I cannot pass dynamic defaults, that is, > > >>> @PluginAttribute(defaultString = TimeZone.getDefault().getID()) is not > > >>> possible. > > >>> > > >>> - I need to silence the formatter: @formatter:off. > > >>> > > >>> Would anybody mind explaining me what is the big win, please? Am I > > >>> missing something? > > >>> > > >>> Best regards. > > >>> > > >> > > >> > > > > > > > > > > > > > -- > Matt Sicker <[email protected]> -- Matt Sicker <[email protected]>
