<div dir="ltr">Is there an inbuilt mechanism in the capabilities ecosystem that disallows system integrators from writing capabilities in the org.wildfly namespace? <div>This is important lest it becomes a wild west in terms of capabilities. :-)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/12/2015 03:22 PM, Brian Stansberry wrote:<br>
> The capability and requirement stuff[1] is far enough along that real<br>
> usage is happening, so actual capability names are being created.[2] I<br>
> wanted to get some input regarding naming conventions for capability<br>
> names so it doesn't devovle into chaos, and so I don't end up making up<br>
> a lot of names people hate.<br>
><br>
> The key thing is capabilities need to be namespaced to avoid collisions<br>
> between capability creators. Beyond that the names should be "good",<br>
> whatever that means (user friendly, properly targeted, not overly tied<br>
> to implementation, etc).<br>
><br>
> My initial thinking on this was:<br>
><br>
> 1) The WildFly family projects own the "org.wildfly" namespace. So all<br>
> capabilities we create fit in that namespace, and no one else puts<br>
> things there. This I think is a must.<br>
><br>
> 2) Capabilities not used by or provided by the WildFly kernel go in<br>
> subspace org.wildfly.extension.<name_of_extension>. Idea there was just<br>
> to avoid naming collisions between different extensions.<br>
><br>
> I don't think 2) is such a great idea any more. A given capability be<br>
> provided by more than one extension, so there isn't a clean conceptual<br>
> mapping. And the word "extension" is really an implementation detail.<br>
><br>
> So, I'm inclined to drop the "extension" bit.<br>
><br>
> Any thoughts on this, or other aspects of how to name capabilities?<br>
<br>
</span>Sounds good to me. I'd like to add that internally, we should make sure<br>
we continue to maintain some registry of our org.wildfly name spaces<br>
somewhere (maybe even just a git repository would be OK) so we don't<br>
conflict among ourselves.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
- DML<br>
</font></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>