<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 30, 2015 at 8:30 PM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":q9" class="a3s" style="overflow:hidden">2) A capability cannot provide services of > 1 value type. It's nice if<br>
capabilities can represent something that's meaningful to an end user,<br>
and there's no reason why something that's meaningful to an end user<br>
might not expose more than one service to other capabilities. If we<br>
limit capabilities to exposing a single service, then we may end up with<br>
multiple capabilities. See [2] for an example case, where a proposed<br>
"org.wildfly.iiop" (nice and simple for an end user to understand)<br>
installs two services, an ORB and a NamingContextExt.</div></blockquote></div><br><br></div>In cases like this capability should still be one service that would than depend on two or more services.<br><div><div class="gmail_extra">and consumer of capability would just get the "aggregator" capability that would than allow access<br></div><div class="gmail_extra">to other two services (or properties on service)<br></div></div></div>