So if you create a domain with the specification: * schemes: http, https, ssh, svn * hostnames: *.acme.org * maven server ids: acme-* * widget colour: red, green
And a plugin asks for credentials with the domain requirements of * maven server id: acme-foobar Then in evaluating the domain specifications, as schemes, hostnames and widget colour do not apply to maven server id, they are all a `soft match` and then the maven server id specification can give its ruling If you asked for credentials with the domain requirements of * widget flavour: barbecue That would also get a `soft match` against all the specifications as none apply, so all the credentials in that domain would be listed also... if this behavour proves problematic for users, we can always add a checkbox to the domain specification definition to require a match of at least one specification... or perhaps a drop down to select between: no misses; match one; match all... but for now I believe `no misses` is the behaviour users want... and it is easy to rectify in a backwards compatible way On 16 August 2013 11:11, Stephen Connolly <[email protected]>wrote: > The way specifications work, by the way, is that if there is a requirement > that a specification applies to then the specification can decide is the > requirement is: > * a hard match - don't check this requirement against any more > specifications > * a soft match - check this requirement against any remaining > specifications > * a hard miss - don't check this requirement against any more > specifications > > If the requirement is of a type that the specification doesn't apply to, > then that is the same as a soft match. > > If all the requirements pass through all the specifications, then the > domain is in play > > > On 16 August 2013 11:03, Stephen Connolly <[email protected] > > wrote: > >> To put this another way, I could have called them credentials zones or >> federation zones or something like that... >> >> they are just a set of specifications that say when these credentials are >> appropriate. The most obvious specifications are hostname, scheme, etc... >> but the specifications and requirements are both extension points. >> >> Given that the id's in the >> server/mirror/repository/pluginRepository/distributionManagement/etc >> sections in the pom are supposed to be kind of organization specific (it's >> only a hint BTW) it would make sense for them to be part of domain >> specifications. >> >> e.g. at CloudBees we have a number of id's we use: >> >> * cloudbees-internal >> * cloudbees-nexus-staging >> * cloudbees-nexus-snapshots >> >> You may notice a trend... they all start with `cloudbees-` >> >> So a Maven Server ID makes sense as a specification... and your config >> file provider can then create it's requirement to be matches by the >> specification attached to the domain. >> >> As a user I'd like to be able to have a comma separated list of IDs with >> * style wildcard support and includes/excludes... e.g. just like the >> current hostname impl >> >> >> On 16 August 2013 10:53, Stephen Connolly < >> [email protected]> wrote: >> >>> My view is that you can add a Maven Server Id domain specification and >>> requirement pair of classes. Thus people can add those specifications to >>> their domains and presto-chango... magic happens >>> >>> >>> On 16 August 2013 10:37, domi <[email protected]> wrote: >>> >>>> Hi Stephan, >>>> >>>> unfortunately I was not able to catch you lately on the chat, but I >>>> have question I want your opinion before I go ahead with my implementation. >>>> >>>> I'm working on the credentials integration for the settigns.xml again >>>> and I have some questions about the usage of domains in the credential >>>> plugin… >>>> I understand that its a good way to group the credentials on the >>>> credentials UI, but it does not help when selecting the correct credentials >>>> at any other location from within a dropdown. In my case DomainRequirements >>>> are not usable to select/limit the correct credentials. This because I have >>>> no idea how the user will have the server configured - thats done in the >>>> pom.xml and not in the settings.xml (he could use scp, http, ssh… to deploy >>>> or copy artifacts around). From a maven point of view it does not matter >>>> how the connection to the server is configured, the credentials are always >>>> stored the same way in the settings.xml. >>>> >>>> From my point of view - an admin would like to group his credentials >>>> like this: e.g. "My slave connection credentials", "my maven settings >>>> credentials",…. and then in the screen for the settings.xml he want to see >>>> all the ones from the group for the maven settings. So my DomainRequirement >>>> would more be like: get me all credentials from the "settings.xml domain A" >>>> instead of "all for http to host X with port Y". >>>> >>>> Whats your view on this? >>>> >>>> regards Domi >>> >>> >>> >> > -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
