On Thu, Nov 9, 2017 at 9:45 AM, nicolas de loof <nicolas.del...@gmail.com> wrote: > As a sample for this > discussion let's consider Mailer plugin build step
And the comment > this code is brain dead :-) > Until you have some clever hack to suggest, it looks to me we will need to > provide guidance for plugin developers for "best practice to implement > Descriptor" so it can be used by configuration-as-code. A lot of this is actually identical to the constraints needed to make code compatible with *Pipeline Syntax*, and more broadly with the `DescribableModel` API. See: https://jenkins.io/doc/developer/plugin-development/pipeline-integration/#constructor-vs-setters > I sounds to me we don't have any way to provide a generic mechanism without > changes to Descriptors in core/plugins - yes I known, this means hundreds > pull-requests Start filing them… The main difficulty is not in writing correct code, which is in fact usually easier than the old way, it is in maintaining deserialization compatibility. So you need to use `readResolve` and occasionally even XStream tricks to load old, awkward property layouts into a logical revised structure. > To reuse Mailer$Descriptor sample, this would require useSMTPAuth to be an > actual nested data structure, not just a boolean flag to configure some > optional attributes. This means that it would have to define a nested java > class to own smtpAuthUserName + smtpAuthPasswordSecret attributes. Yes. `f:optionalProperty` and a nested `Describable`. See for example `HeteroList` in `ui-samples`. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3Vq3AVbvMFQDiB2xApKiqT%3Dswcsr%3D606V5OuKVrkKZmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
