7:33 a.m.
The problem is, that's not *really* central. The version of
wildfly-core does not impact what namespaces exist or are recognized by
subsystems. However, putting the registry in that repository means that
certain names, which are possibly not even referenced from wildfly-core,
become unavailable for no good reason.
On the other hand, having a separate registry encourages add-on packages
and other third parties to participate in registration without the
additional coordination overhead required in creating releases for the
change to become visible to the greater world. This becomes even more
significant as we maintain multiple branches.
Finally, having external name registries is standard practice for plenty
of situations similar to this one (RFC implementations for example), for
all the reasons I've given above.
On 06/22/2015 06:54 AM, Darran Lofthouse wrote:
IMO if we add it to our source repo we should just add it to our
source,
that would also provide a central point other subsystems can reference
it from.
Having a policy of put it in a text file in our source repo but don't
allow it in a shared class file seems wrong.
On 13/06/15 10:00, Kabir Khan wrote:
>
>> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>>
>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>
>>>
>>> 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.
>>>
>>
>> Like a text file per capability, with some doc on the capability in the
>> file? Files organized in a tree from the names?
>>
>> That sounds good; much better than some wiki.
> +1
> I don’t know enough about this yet to suggest a format, but having it somewhere in
the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page
we used for AS 7.
>>
>> --
>> 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
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)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
--
- DML