2018-04-17 22:05 GMT+02:00 Jesse Glick <[email protected]>: > On Tue, Apr 17, 2018 at 2:03 PM, nicolas de loof > <[email protected]> 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 [email protected]. > 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 [email protected]. 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.
