2018-04-17 22:05 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>: > On Tue, Apr 17, 2018 at 2:03 PM, nicolas de loof > <nicolas.del...@gmail.com> wrote: > > the yaml schema is for a specific version of jenkins-core + plugin. > > Any change to a plugin will change this model, this will happen any time > a > > DataBoundConstructor is modified > > Well, typically we would expect parameters to be compatible after a > plugin update, so that if for example a `@DataBoundSetter` method > needs to be `@Deprecated`, it is removed from databinding but still > accessible as a Java setter. The compatibility policy for such > refactorings does need to be defined. Currently we only expect plugins > to be compatible in their XStream settings form, plus Pipeline `Step`s > and any `Describable`s used by them need to continue to accept > parameters that worked before. >
we exclude Deprecated setters as potential CasC attributes, so this wouldn't help As you said there's no expectation for compatibility at this level we could rely on. That being said I don't consider this to be an issue : with CasC we can produce a schema and tooling to discover such compatibility issue and let end-user know before they apply to production. > > > I would anyway expect Credentials plugin to own this code, so such > decision > > is made from maintainer > > JEP-201 is introducing a new overall Jenkins feature, and the > Credentials plugin is a longstanding piece of plumbing, so I would > expect JEP-201 developers to address this particular integration. > CasC plugin demonstrate we can support it with current implementation, even if this one relies on some uncommon yaml syntax. I consider credentials-plugin maintainer to have a better vision of what should be exposed to end-user than me. > > > I don't understand why this plugin adopted this > > odd design - most probably for compatibility reasons > > I do not think compatibility had anything to do with it. The > configuration model of Credentials is that you have various providers, > inside of each of which you can create various domains, each of which > then contains a set of credentials. The Java-level structure is more > or less arbitrary and was not intended to map directly to Jenkins > databinding, because its UI manifestation is not a single > configuration screen. > > > sounds to me job-dsl could support a yaml syntax (just by switching > > parser) > > Why would you need `job-dsl` at all? You already have a general system > for binding YAML to `Describable`s. You would need a bit of extra code > to bind some syntax to `TopLevelItem` and > `DirectlyModifiableTopLevelItemGroup`, and a call to JENKINS-50173 if > and when written. > 1. Job class hierarchy is full of hand written JSON parsing so we can't use same discovery approach 2. job-dsl is very popular for this purpose, I don't want to spend time re-inventing the wheel for a successful solution. I'd like job-dsl support to be option in JCasC, so we do support this approach but some alternate way is also possible in a future release. > -- > 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/CANfRfr00%2BpNy%2BSfbY%2BLeye-GYd0v7Q% > 2BxttRZCJddyv_Y8fgOyA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. > -- 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/CANMVJzn%3Dx0bUXrqPECiFLo-5Fpd3PkVxwVcm%2BvnDBPbNDg%3DDYg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
