<div dir="ltr">It probably is not a big deal TBH.  A proper documented wiki with guidelines for capabilities is all you need. A capability namespace enforcement model (though a capability of its own) is an overkill.  I was just curious. ;)<div><br></div><div>May I suggest adding some diagrams on your capabilities wiki page explaining the key concepts behind it. I had to dig deep to understand the differences between capabilities and modules.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 4:34 PM, Brian Stansberry <span dir="ltr">&lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No, there isn&#39;t.<br>
<span class=""><br>
On 6/12/15 4:30 PM, Anil Saldhana wrote:<br>
&gt; Is there an inbuilt mechanism in the capabilities ecosystem that<br>
&gt; disallows system integrators from writing capabilities in the<br>
&gt; org.wildfly namespace?<br>
&gt; This is important lest it becomes a wild west in terms of capabilities. :-)<br>
&gt;<br>
&gt; On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd &lt;<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a><br>
</span><div><div class="h5">&gt; &lt;mailto:<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     On 06/12/2015 03:22 PM, Brian Stansberry wrote:<br>
&gt;     &gt; The capability and requirement stuff[1] is far enough along that real<br>
&gt;     &gt; usage is happening, so actual capability names are being created.[2] I<br>
&gt;     &gt; wanted to get some input regarding naming conventions for capability<br>
&gt;     &gt; names so it doesn&#39;t devovle into chaos, and so I don&#39;t end up making up<br>
&gt;     &gt; a lot of names people hate.<br>
&gt;     &gt;<br>
&gt;     &gt; The key thing is capabilities need to be namespaced to avoid collisions<br>
&gt;     &gt; between capability creators. Beyond that the names should be &quot;good&quot;,<br>
&gt;     &gt; whatever that means (user friendly, properly targeted, not overly tied<br>
&gt;     &gt; to implementation, etc).<br>
&gt;     &gt;<br>
&gt;     &gt; My initial thinking on this was:<br>
&gt;     &gt;<br>
&gt;     &gt; 1) The WildFly family projects own the &quot;org.wildfly&quot; namespace. So all<br>
&gt;     &gt; capabilities we create fit in that namespace, and no one else puts<br>
&gt;     &gt; things there. This I think is a must.<br>
&gt;     &gt;<br>
&gt;     &gt; 2) Capabilities not used by or provided by the WildFly kernel go in<br>
&gt;     &gt; subspace org.wildfly.extension.&lt;name_of_extension&gt;. Idea there was just<br>
&gt;     &gt; to avoid naming collisions between different extensions.<br>
&gt;     &gt;<br>
&gt;     &gt; I don&#39;t think 2) is such a great idea any more. A given capability be<br>
&gt;     &gt; provided by more than one extension, so there isn&#39;t a clean conceptual<br>
&gt;     &gt; mapping. And the word &quot;extension&quot; is really an implementation detail.<br>
&gt;     &gt;<br>
&gt;     &gt; So, I&#39;m inclined to drop the &quot;extension&quot; bit.<br>
&gt;     &gt;<br>
&gt;     &gt; Any thoughts on this, or other aspects of how to name capabilities?<br>
&gt;<br>
&gt;     Sounds good to me.  I&#39;d like to add that internally, we should make sure<br>
&gt;     we continue to maintain some registry of our org.wildfly name spaces<br>
&gt;     somewhere (maybe even just a git repository would be OK) so we don&#39;t<br>
&gt;     conflict among ourselves.<br>
&gt;<br>
&gt;     --<br>
&gt;     - DML<br>
&gt;     _______________________________________________<br>
&gt;     wildfly-dev mailing list<br>
</div></div>&gt;     <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>&gt;<br>
&gt;     <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<span class="im HOEnZb">&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; wildfly-dev mailing list<br>
&gt; <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
&gt;<br>
<br>
<br>
</span><span class="im HOEnZb">--<br>
Brian Stansberry<br>
Senior Principal Software Engineer<br>
JBoss by Red Hat<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>