[wildfly-dev] Capability naming conventions

[Darran Lofthouse]

On 12/06/15 22:30, Anil Saldhana wrote:
> 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. :-)

Actually it is desirable that system integrators do use the names we 
define, if we define that a capability is provided under a specific name 
the integrator can do two different things: -

  1 - Depend on a capability that we supply.
  2 - Provide their own implementation of that capability.

e.g. in the future I would love to see a situation where a third party 
company specialising in security software could add their own subsystem 
that provides the TrustManager capability to plug in their own trust 
infrastructure.

> On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <david.lloyd at redhat.com
> <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>