6:52 a.m.
It does make more sense to extract the data from the files versus any
manual maintenance. That adds some complexity to the plugin but not so
much; e.g. the JBoss Tools generator Jeff linked at a glance doesn't
involve any sophisticated parsing, parsing libraries etc.
Naively, it would be good if any parsing of the files could be done during
feature pack generation instead of at provisioning time. My impression is
our present handling of the schemas is done at provisioning time.
On Tue, Aug 25, 2020 at 9:53 PM Jim Ma <ema(a)redhat.com> wrote:
It looks we can add something in gallon plugin to scan the xsd file
under
schema folder from each subsystem to create this catalog file. It gets the
value of "xmlns"[1] with this xsd file name and generate the catalog
element like :
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
prefer="public">
<uri name="urn:jboss:domain:jaxrs:2.0"
uri="file://local/jboss-as-jaxrs_2.0.xsd"/>
Your uri example brings up another question I had about these catalogs.
For our use case these would need to be relative paths. When I google
around about these how the resolution of relative paths is meant to work
seems pretty vague. There are ways to specify in the catalog what absolute
path they are relative to, but that seems like just a way to externalize
that part from all the individual details. But in our case we have no way
to know the absolute path.
My general impression is good practice for such cases is to treat relative
paths as relative to the dir with the catalog file, e.g.
<unknown_part>/docs/schemas in our case. That would be fine, but how
</catalog>
[1]
https://github.com/wildfly/wildfly/blob/master/jaxrs/src/main/resources/s...
Cheers,
Jim
On Wed, Aug 26, 2020 at 4:33 AM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> There were problems recently with the mail list and this didn't go
> through, so resending now...
>
> On Thu, Aug 20, 2020 at 9:49 PM Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>> Does anyone have any ideas on how we could generate a catalog.xml
>> file[1] that we could ship in docs/schema along with all our xsds? This
>> would provide a mapping between our xml namespace URNs and the associated
>> xsd file in that same dir.
>>
>> For simplicity's sake this could be limited to the server / subsystem
>> configuration schemas.
>>
>> I think this would need to be handled by the WildFly galleon plugin.
>> Such a catalog would need to combine data from the various maven modules
>> that provide schemas. It's the WF galleon plugin feature pack generation or
>> provisioning functions that pull together data from all the various
>> modules.
>>
>> A not particular elegant possibility is to stick property files in the
>> various 'schema' dirs in the source, e.g.
>> https://github.com/wildfly/wildfly/tree/master/jaxrs/src/main/resources/s....
>> The properties map the urns to the xsd file names. Something in the galleon
>> plugin knows to look for those and aggregates the contents and generates
>> the catalog.
>>
>> This question was sparked by a question from Fred Bricon on twitter:
>> https://twitter.com/fbricon/status/1293911221771485185
>>
>> [1] https://www.oasis-open.org/committees/entity/spec-2001-08-06.html
>>
>> Best regards,
>> Brian
>>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat