[wildfly-dev] Capability naming conventions

[Anil Saldhana]

Is there an inbuilt mechanism in the capabilities ecosystem that disallows
system integrators from writing capabilities in the org.wildfly namespace?
This is important lest it becomes a wild west in terms of capabilities. :-)

On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 06/12/2015 03:22 PM, Brian Stansberry wrote:
> > The capability and requirement stuff[1] is far enough along that real
> > usage is happening, so actual capability names are being created.[2] I
> > wanted to get some input regarding naming conventions for capability
> > names so it doesn't devovle into chaos, and so I don't end up making up
> > a lot of names people hate.
> >
> > The key thing is capabilities need to be namespaced to avoid collisions
> > between capability creators. Beyond that the names should be "good",
> > whatever that means (user friendly, properly targeted, not overly tied
> > to implementation, etc).
> >
> > My initial thinking on this was:
> >
> > 1) The WildFly family projects own the "org.wildfly" namespace. So all
> > capabilities we create fit in that namespace, and no one else puts
> > things there. This I think is a must.
> >
> > 2) Capabilities not used by or provided by the WildFly kernel go in
> > subspace org.wildfly.extension.<name_of_extension>. Idea there was just
> > to avoid naming collisions between different extensions.
> >
> > I don't think 2) is such a great idea any more. A given capability be
> > provided by more than one extension, so there isn't a clean conceptual
> > mapping. And the word "extension" is really an implementation detail.
> >
> > So, I'm inclined to drop the "extension" bit.
> >
> > Any thoughts on this, or other aspects of how to name capabilities?
>
> Sounds good to me.  I'd like to add that internally, we should make sure
> we continue to maintain some registry of our org.wildfly name spaces
> somewhere (maybe even just a git repository would be OK) so we don't
> conflict among ourselves.
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/d1700db2/attachment-0001.html