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 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?).
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.
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.
--
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/CANfRfr3e56PQf4vrDLPjPU11MxzKX3L%3DR%2BQVROgyAyuKRYB97A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
