[wildfly-dev] Capability naming conventions

[Anil Saldhana]

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

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.

On Fri, Jun 12, 2015 at 4:34 PM, Brian Stansberry <
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>> 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
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> 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/eb0e00f1/attachment.html