Alright, PoCs are in the trunk right now. I've only got builder classes in PatternLayout and HtmlLayout. I've also updated all the @PluginAttribute usage where defaultValue() was used before to use their appropriate typed attributes instead.
On 26 May 2014 14:18, Matt Sicker <[email protected]> wrote: > I'm working on PoC's for those things before I go and make widespread > changes to everything. I'll follow up with one in an hour or two. > > > On 26 May 2014 08:27, Gary Gregory <[email protected]> wrote: > >> On Sun, May 25, 2014 at 11:44 PM, Matt Sicker <[email protected]> wrote: >> >>> 1. I'm removing @PluginDefault and instead using an additional attribute >>> on @PluginAttribute. >>> >> >> Great. Please see my other thread about default primitive values and >> @IntPluginAttribute, and so on. >> >> >> 2. I'm refactoring the logic in the giant if/else-if block in >>> PluginBuilder to a system vaguely similar to how the Bean Validation spec >>> works. >>> 3. I'm updating all the places where @PluginDefault is used to use the >>> simpler system. >>> 4. I've only refactored the @PluginAttribute code so far, but it's >>> working. I'll continue with the other @PluginAnnotations afterward. >>> >>> >> First, I am grateful for all of the work Matt has been put in here and in >> other areas, so please take this constructively. >> >> >>> Future work: >>> 1. Adding support for building a plugin using a builder class instead of >>> a factory method. >>> >> >> But why? This seems a lot more complicated than the simple factory >> methods we now have. Who is the customer here? The unit tests? >> >> I am asking because this seems to add a lot of code and complexity for an >> unknown gain, or at least the case is not clear to me. Perhaps I missed a >> thread on this ML about presenting it. >> >> >>> 2. Converting existing plugin factory methods to builder classes. >>> >> >> As above. >> >> >>> 3. Updating the jazillion unit tests to use said builder classes (which >>> is actually rather nice). >>> >> >> I guess I'd expect to see a proposal and example on the ML first before >> such a large scale set of changes. >> >> Gary >> >> >>> 4. Removing factory methods altogether (perhaps replacing >>> @PluginBuilderFactory with @PluginFactory). >>> >>> The good thing about all this is it's more along the line of >>> refactoring, so it's not necessary to complete it all by 2.0. It will, >>> however, be useful for plugin authors to not have to fix their plugins for >>> 2.1 again. >>> >>> -- >>> Matt Sicker <[email protected]> >>> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
