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&gt; 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

We have one in JBoss Tools that gets regenerated each time a new version of Wildfly or EAP is out: https://github.com/jbosstools/jbosstools-server/blob/master/as/plugins/or... The tool that regenerates its: https://github.com/jbosstools/jbosstools-server/blob/master/as/plugins/or... On Wed, Aug 26, 2020 at 5:00 AM Jim Ma <ema(a)redhat.com&gt; 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"/> > </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&gt; 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&gt; 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 > > _______________________________________________ > 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 -- Jeff Maury Manager, DevTools Red Hat EMEA <https://www.redhat.com> jmaury(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com> <https://redhat.com/summit>

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&gt; 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&gt; 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&gt; 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

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 <mailto: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/resour.... 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