Yes, that’s a good idea. On Fri, Jan 17, 2020 at 04:44 Volkan Yazıcı <[email protected]> wrote:
> Shall we remove the @deprecated entry in javadocs until the design is > finalized and merged to master? > > On Thu, Jan 16, 2020 at 5:49 PM 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]>
