This message is a follow up for discussion on https://github.com/jenkinsci/jep/pull/31#discussion_r149598856
configuration-as-code <https://github.com/jenkinsci/jep/tree/master/jep/201> prototype include generic mechanism to configure arbitrary jenkins component relying on @DataBound* ui-binding methods. but configuration also include Descriptors, and many of them do rely on programmatic data-binding parsing JSONObject. As a sample for this discussion let's consider Mailer plugin build step <https://github.com/jenkinsci/mailer-plugin/blob/master/src/main/java/hudson/tasks/Mailer.java#L233> This one has attributes, which don't match the UI databound attributes. For sample (for legacy reasons) Java attribute smtpHost is expose on UI as smtpServer (here <https://github.com/jenkinsci/mailer-plugin/blob/master/src/main/java/hudson/tasks/Mailer.java#L378> ) This one uses an optional block in configuration, and as a result it relie son a pseudo boolean attribute useSMTPAuth <https://github.com/jenkinsci/mailer-plugin/blob/master/src/main/java/hudson/tasks/Mailer.java#L383> (== descriptor.smtpAuthUserName!=null <https://github.com/jenkinsci/mailer-plugin/blob/master/src/main/resources/hudson/tasks/Mailer/global.jelly#L35> ) and unset related attributes to null if not selected. So - We can rely on getXXX methods to discover attributes - we can guarantee they're defined - BUT we can't guess psuedo-attributes like useSMTPAuth <https://github.com/jenkinsci/mailer-plugin/blob/master/src/main/java/hudson/tasks/Mailer.java#L383>, neither can we guess the nested JSON document this one involves : { "useSMTPAuth" : { "smtpAuthUserName" : ..., "smtpAuthPasswordSecret" : ... } } As a resume : - We can't invoke @DataBoundSetters for those attributes. Some exist for Mailer bu tin many cases they don't (they're not required by a Descriptor) - We can't event directly set attributes using Field.setAccessible hack, as name isn't guaranteed to match (see smtpHost != smtpServer) - We can't invoke configure(StaplerRequest, JSONObject) as we can't guess the required nested JSON document structure 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. 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 :'( Can we just ask them to rely on @DataBound ? Please remind a Descriptor is a *mutable* object, i.e if someone un-select some option, the target component won't get attribute reset to null. 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. Any thoughts ? -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DvkFy6iyOGdHZbpkqYi_cE9Da7XYas0_S4NKaYe2C1tw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
