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

Cheers,
Jim

On Wed, Aug 26, 2020 at 4:33 AM Brian Stansberry <brian.stansberry@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@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/schema. 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


Best regards,
Brian


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat