2018-04-17 17:58 GMT+02:00 Jesse Glick <[email protected]>: > Some things that might otherwise have gotten lost in IRC. > > > About the automatic inference of symbols like `ldap` from > `hudson.security.LDAPSecurityRealm`: this seems like a nice trick to > use when prototyping the JEP, so you can see realistic stuff working > before plugins are updated to use `@Symbol`. But I do not think this > should be retained in a 1.0 version—all supported plugins should be > given the annotation. Reasoning: > > · Adding an annotation poses no risk to plugin stability, so there is > no reason for a maintainer to object to it. > · Symbols must be unique within their extension point (for example > there may be only one `SecurityRealm` named `ldap`), so they must be > chosen carefully and deliberately. > · People might begin relying on the inferred names and then it would > be a compatibility issue to fix this later. > > 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, this is the price to pay for allignment with UI databinding. As a result, I don't think we should expect any compatibility on version upgrades. If you want to run with new version of plugins, run a test master or any JCasC validation tool before.
> > The credentials domain syntax, IIRC something like > > system: > ? # global > : -credentials > # … > > baffles everyone who sees it. Just because internally `credentials` > uses a `Map` from (I guess) domains to lists of credentials does not > mean you must reflect that in YAML syntax. You should rather model a > list of credentials, each of which may have an optional attribute for > the domain (ID?). > The idea here was to estimate the minimal required code base to offer glue code for credentials. This is definitively not for 1.0 I would anyway expect Credentials plugin to own this code, so such decision is made from maintainer - I don't understand why this plugin adopted this odd design - most probably for compatibility reasons - the web UI offering a hierarchical representation of registered credentials. > > It is no excuse that you are trying to keep things mapped tightly to > the databinding model in the plugin, because Jenkins databinding does > not have any standard support for `Map`s at all—this is all bound to > custom UI screens in `credentials`. Therefore it is reasonable for > JCasC to also have a custom converter. Plugins which use simple > databinding, which would consist of `List`s of `Describable`s only, > would not need any custom code. > As I said, I expect such things to take place within plugins themsleves, either with custom JCasC _or_ by changing the databound model > > > Using Job DSL Groovy to create jobs is fine as a short-term workaround > but should not be how `TopLevelItem`s are defined in 1.0 I think. > There should be native YAML syntax for this, based on the same > databinding model as any other settings. As `@Symbol` is adopted, > these should look structurally similar anyway. > Agree, sounds to me job-dsl could support a yaml syntax (just by switching parser). Need to investigate how to generate the adequate schema and documentation > > -- > 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/CANfRfr3e56PQf4vrDLPjPU11MxzKX > 3L%3DR%2BQVROgyAyuKRYB97A%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/CANMVJznHMAPGtfava_DgxpNKgLGsEsWfAGgUiuPbNMRA3wbxfA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
