On Wed, Aug 26, 2020 at 9:39 AM Jim Ma <ema(a)redhat.com> wrote:
On Wed, Aug 26, 2020 at 7:52 PM Brian Stansberry <
> 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
> 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" with this xsd file name and generate the
>> catalog element like :
>> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
>> <uri name="urn:jboss:domain:jaxrs:2.0"
> 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
We set an URIResolver to resolve this <unknown_part> prefix to
$wildfly_home or some place ?
Oops, I got distracted and didn't finish a sentence. But yes, I figure
whoever is using the catalog probably has to do something like that.
>> 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 that we could ship in docs/schema along with all our xsds? This
>>>> would provide a mapping between our xml namespace URNs and the
>>>> xsd file in that same dir.
>>>> For simplicity's sake this could be limited to the server /
>>>> 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
>>>> provisioning functions that pull together data from all the various
>>>> A not particular elegant possibility is to stick property files in the
>>>> various 'schema' dirs in the source, e.g.
>>>> The properties map the urns to the xsd file names. Something in the
>>>> 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://www.oasis-open.org/committees/entity/spec-2001-08-06.html
>>>> Best regards,
>>> 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
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
Manager, Senior Principal Software Engineer