[wildfly-dev] Capability naming conventions

[Brian Stansberry]

On 6/12/15 4:41 PM, Anil Saldhana wrote:
> 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. ;)
>

Ok, good, as that wouldn't be trivial!

> 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.
>

I want to add a section to the "Extending WildFly" docs[1]. This 
distinction is a good one to clarify.

Perhaps I should call if a "managed capability" as this is all about 
stuff that functionality via the WildFly Core management layer.

The distinction between an extension and a managed capability is another 
good one.

[1] https://docs.jboss.org/author/display/WFLY9/Extending+WildFly

> On Fri, Jun 12, 2015 at 4:34 PM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>
>     No, there isn't.
>
>     On 6/12/15 4:30 PM, 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. :-)
>     >
>     > On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>      > <mailto: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>
>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     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
>
>


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