4:41 p.m.
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(a)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(a)redhat.com
> <mailto:david.lloyd@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev