[wildfly-dev] Capability naming conventions

Brian Stansberry brian.stansberry at redhat.com
Fri Jun 12 16:22:16 EDT 2015


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?

FYI, see [3] for some names of capabilities that will be used by the kernel.

[1] The "Runtime" aspect of https://developer.jboss.org/docs/DOC-52712
[2] https://github.com/wildfly/wildfly/pull/7596
[3] https://developer.jboss.org/docs/DOC-53383

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list