users-request_at_jaxb.java.net wrote:
>Table of contents:
>
>1. Re: Bug or not: trying to use seperate schema compilation using maven-jaxb2-plugin - Aleksei Valikov <valikov_at_gmx.net>
>2. Re: Bug or not: trying to use seperate schema compilation using maven-jaxb2-plugin - manuel.siggen_at_vd.ch
>3. Re: Bug or not: trying to use seperate schema compilation using maven-jaxb2-plugin - Rogier Enders <rogier.enders_at_gmail.com>
>
>
>Hi Rogier,
>
>I think, your reasoning is quite correct. To note, this is not a bug
>in the maven-jaxb2-plugin, it is more a problem with XJC itself.
>maven-jaxb2-plugin only wraps XJC.
>
>I'm also coming over this issue time after time. I always managed to
>resolve it somehow, but I can't formulate the method at the moment.
>Would you please put a sample demo project together - I'll look into
>it. We'll probably have to file an issue for XJC since I don't think
>this can be fixed in the Maven plugin.
>
>Bye,
>/lexi
>
>
>On Wed, Aug 14, 2013 at 3:33 PM, Rogier Enders <rogier.enders_at_gmail.com> wrote:
>> Hi Valikov,
>>
>> I'm trying to generate sources from a set of xml schemas using the
>> "maven-jaxb2-plugin" version 0.8.3.
>>
>> The schemas refer to each other using an import with a namespace and a
>> schemaLocation attibute. The schemaLocation attribute is relative.
>>
>> Using a catalog file (in XML format, Oasis Catalog standard version 1.1) I
>> managed to change the schemaLocation using a systemSuffix to an uri
>> reference resource inside a Maven artifact.
>>
>> First: schema A sources are generated using the plugin without any
>> configuration. The jar is uploaded to the maven repository.
>>
>> Schema B sources are generated using the pluging. The A.jar is defined as a
>> dependency and useDependenciesAsEpisode is set to true. There is also a
>> catalog parameter with a systemSuffix. This jar is also uploaded to the
>> maven repository.
>>
>> All works well for schema B which imports schema A with a relative
>> schemaLocation, using episodes.
>>
>> Now I'm trying to generate sources for a schema C which import B and A. This
>> results in the following error:
>> "[ERROR] Error while parsing schema(s).Location [
>> jar:file:/home/rogier/.m2/repository/nl/renders/address-rel/1.0/address-rel-1.0.jar!/address.xsd{9,13}].
>> org.xml.sax.SAXParseException: 'address' is already defined"
>>
>> It seams like the plugin is generating sources for schema C, since this
>> schema imports B and A, sources are also generated for these schemas but
>> since B imports A, it tries to generate another set of sources for schema A
>> which results in the error "is already defined".
>>
>> If I remove the schemaLocation attrinute from the XSD schema in the
>> generated B.jar, it works well since the sources from schema A are only
>> generated once.
>>
>> Is this a bug in the plugin or am I missing something here? If you like I
>> can send to some sources to reproduce the problem.
>>
>> With regards,
>>
>> Rogier Enders
>
>Hi Rogier, hi Aleksei,
>
>I've stumble upon a similar problem sometimes ago and here what I've
>found. I think the problem is that xjc keeps an internal mapping of all
>schemas in the form of :
>
> schemaLocation -> nameSpace
>
>In the first example with two schemas A and B (see email below), and with
>a maven-jaxb2-plugin configured like this :
>
> <schemaIncludes>
> <include>b.xsd</include>
> </schemaIncludes>
>
>... then xjc's internal mapping is something like :
>
> - 'b.xsd' -> 'http://ns.example.com/b'
> - 'http://schemas.example.com/a.xsd' -> 'http://ns.example.com/a'
>
>Now, with three schemas A, B and C and the maven-jaxb2-plugin configured
>like this :
>
> <schemaIncludes>
> <include>b.xsd</include>
> <include>c.xsd</include>
> </schemaIncludes>
>
>...then xjc's internal mapping is something like :
>
> - 'c.xsd' -> 'http://ns.example.com/c'
> - 'b.xsd' -> 'http://ns.example.com/b'
> - 'http://schemas.example.com/b.xsd' -> 'http://ns.example.com/b'
> - 'http://schemas.example.com/a.xsd' -> 'http://ns.example.com/a'
>
>=> notice how the B namespace is included twice !
>
>I've solved it the following way : I use a dummy file 'main.xsd' which
>imports with all the namespace I need :
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:jxb="
>http://java.sun.com/xml/ns/jaxb" jxb:version="2.0">
> <xs:import namespace="http://ns.example.com/b"
>schemaLocation="http://schemas.example.com/b.xsd" />
> <xs:import namespace="http://ns.example.com/c"
>schemaLocation="http://schemas.example.com/c.xsd" />
> </xs:schema>
>
>... and then use it as entry point for the maven-jaxb2-plugin :
>
> <schemaIncludes>
> <include>main.xsd</include>
> </schemaIncludes>
>
>It works because the 'main.xsd' is never included/imported by other xsd.
>With this configuration, xjc's internal mapping becomes something like :
>
> - 'main.xsd' -> '<nonamespace>'
> - 'http://schemas.example.com/c.xsd' -> 'http://ns.example.com/c'
> - 'http://schemas.example.com/b.xsd' -> 'http://ns.example.com/b'
> - 'http://schemas.example.com/a.xsd' -> 'http://ns.example.com/a'
>
>
>Hope it helps !
>Best regards,
>
> Manuel Siggen
>
>
>________________________________________
>Manuel Siggen - Ingénieur de développement logiciel
>Etat de Vaud, Département des Infrastructures et des Ressources Humaines
>(DIRH)
>Direction des Systèmes d'Information (DSI)
>Pôle Référentiels
>Avenue de Longemalle 1, CH-1020 Renens
>Tel:+41 (0)21 316 26 43 Fax:+41 (0)21 316 27 26
>manuel.siggen_at_vd.ch - www.vd.ch
>
>
>
>De : Aleksei Valikov <valikov_at_gmx.net>
>A : Rogier Enders <rogier.enders_at_gmail.com>
>Cc : "users_at_jaxb.java.net" <users_at_jaxb.java.net>
>Date : 15.08.2013 08:09
>Objet : Re: Bug or not: trying to use seperate schema compilation using
>maven-jaxb2-plugin
>Envoyé par : aleksei.valikov_at_gmail.com
>
>
>
>Hi Rogier,
>
>I think, your reasoning is quite correct. To note, this is not a bug
>in the maven-jaxb2-plugin, it is more a problem with XJC itself.
>maven-jaxb2-plugin only wraps XJC.
>
>I'm also coming over this issue time after time. I always managed to
>resolve it somehow, but I can't formulate the method at the moment.
>Would you please put a sample demo project together - I'll look into
>it. We'll probably have to file an issue for XJC since I don't think
>this can be fixed in the Maven plugin.
>
>Bye,
>/lexi
>
>
>On Wed, Aug 14, 2013 at 3:33 PM, Rogier Enders <rogier.enders_at_gmail.com>
>wrote:
>> Hi Valikov,
>>
>> I'm trying to generate sources from a set of xml schemas using the
>> "maven-jaxb2-plugin" version 0.8.3.
>>
>> The schemas refer to each other using an import with a namespace and a
>> schemaLocation attibute. The schemaLocation attribute is relative.
>>
>> Using a catalog file (in XML format, Oasis Catalog standard version 1.1)
>I
>> managed to change the schemaLocation using a systemSuffix to an uri
>> reference resource inside a Maven artifact.
>>
>> First: schema A sources are generated using the plugin without any
>> configuration. The jar is uploaded to the maven repository.
>>
>> Schema B sources are generated using the pluging. The A.jar is defined
>as a
>> dependency and useDependenciesAsEpisode is set to true. There is also a
>> catalog parameter with a systemSuffix. This jar is also uploaded to the
>> maven repository.
>>
>> All works well for schema B which imports schema A with a relative
>> schemaLocation, using episodes.
>>
>> Now I'm trying to generate sources for a schema C which import B and A.
>This
>> results in the following error:
>> "[ERROR] Error while parsing schema(s).Location [
>>
>jar:file:/home/rogier/.m2/repository/nl/renders/address-rel/1.0/address-rel-1.0.jar!/address.xsd{9,13}].
>> org.xml.sax.SAXParseException: 'address' is already defined"
>>
>> It seams like the plugin is generating sources for schema C, since this
>> schema imports B and A, sources are also generated for these schemas but
>> since B imports A, it tries to generate another set of sources for
>schema A
>> which results in the error "is already defined".
>>
>> If I remove the schemaLocation attrinute from the XSD schema in the
>> generated B.jar, it works well since the sources from schema A are only
>> generated once.
>>
>> Is this a bug in the plugin or am I missing something here? If you like
>I
>> can send to some sources to reproduce the problem.
>>
>> With regards,
>>
>> Rogier Enders
>
>
>Hi Manual and Aleksei,
>
>Attached is a sample project.
>Do a 'mvn clean install' of the 'address' project.
>Do a 'mvn clean install' of the 'customer' project.
>Do a 'mvn clean package' of the 'order' project, which will result in the
>error 'org.xml.sax.SAXParseException: 'address' is already defined'.
>
>Hopes this helps.
>
>I think Manual is right about the internal map with namespaces of
>schemaLocations. Since the schema's use relative schemaLocation elements,
>they are first resolved to absolute locations. Since the absolute location
>of the Address schema is different when it is referenced in the Customer
>schema than in the Order schema, the Address schema is parsed twice which
>results in the error.
>
>To prove this, if I remove the schemaLocation attribute from the Customer
>schema in the Customer artifact, it works.
>
>I also try to use absolute schemaLocation in the schemas and use a catalog
>to change the SystemId. Like this:
><systemSuffix systemIdSuffix="address.xsd"
>uri="maven:nl.renders:address-abs-suffix!/address.xsd"/>
><systemSuffix systemIdSuffix="customer.xsd"
>uri="maven:nl.renders:customer-abs-suffix!/customer.xsd"/>
>This works also since the importLocation is not normalized to a absolute
>path.
>
>I tried to rewrite the SystemId, like this:
><rewriteSystem systemIdStartString = "http://www.example.com/address.xsd"
>rewritePrefix="maven:nl.renders:address-abs-rewrite!/address.xsd"/>
> <rewriteSystem systemIdStartString = "http://www.example.com/customer.xsd"
>rewritePrefix="maven:nl.renders:customer-abs-rewrite!/customer.xsd"/>
>The resulted in the error: Caused by: java.net.MalformedURLException: no !/
>in spec.
>Seams like the CatalogResolver resolves the schemaLocation for the Order
>schema fine but and changes the schemaLocation for the Customer schema to
>'maven:nl.renders:address-abs-suffix!/address.xsd' which is invalid.
>
>I also tried to set the prefer attribute (system or public) in the
>catalog.xml but is seams like this is ignored.
>
>If you like I also have sample projects of the variants mentioned above.
>
>I'm going to try Manual suggestion and let you know the result.
>
>With regards,
>
>Rogier
>
>
>2013/8/15 <manuel.siggen_at_vd.ch>
>
>> Hi Rogier, hi Aleksei,
>>
>> I've stumble upon a similar problem sometimes ago and here what I've
>> found. I think the problem is that xjc keeps an internal mapping of all
>> schemas in the form of :
>>
>> schemaLocation -> nameSpace
>>
>> In the first example with two schemas A and B (see email below), and with
>> a maven-jaxb2-plugin configured like this :
>>
>> <schemaIncludes>
>> <include>b.xsd</include>
>> </schemaIncludes>
>>
>> ... then xjc's internal mapping is something like :
>>
>> - 'b.xsd' -> 'http://ns.example.com/b'
>> - 'http://schemas.example.com/a.xsd' -> 'http://ns.example.com/a'
>>
>> Now, with three schemas A, B and C and the maven-jaxb2-plugin configured
>> like this :
>>
>> <schemaIncludes>
>> <include>b.xsd</include>
>> <include>c.xsd</include>
>> </schemaIncludes>
>>
>> ...then xjc's internal mapping is something like :
>>
>> - 'c.xsd' -> 'http://ns.example.com/c'
>> - 'b.xsd' -> 'http://ns.example.com/b'
>> - 'http://schemas.example.com/b.xsd' -> 'http://ns.example.com/b'
>> - 'http://schemas.example.com/a.xsd' -> 'http://ns.example.com/a'
>>
>> => notice how the B namespace is included twice !
>>
>> I've solved it the following way : I use a dummy file 'main.xsd' which
>> imports with all the namespace I need :
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:jxb="
>> http://java.sun.com/xml/ns/jaxb" jxb:version="2.0">
>> <xs:import namespace="http://ns.example.com/b"
>> schemaLocation="http://schemas.example.com/b.xsd" />
>> <xs:import namespace="http://ns.example.com/c"
>> schemaLocation="http://schemas.example.com/c.xsd" />
>> </xs:schema>
>>
>> ... and then use it as entry point for the maven-jaxb2-plugin :
>>
>> <schemaIncludes>
>> <include>main.xsd</include>
>> </schemaIncludes>
>>
>> It works because the 'main.xsd' is never included/imported by other xsd.
>> With this configuration, xjc's internal mapping becomes something like :
>>
>> - 'main.xsd' -> '<nonamespace>'
>> - 'http://schemas.example.com/c.xsd' -> 'http://ns.example.com/c'
>> - 'http://schemas.example.com/b.xsd' -> 'http://ns.example.com/b'
>> - 'http://schemas.example.com/a.xsd' -> 'http://ns.example.com/a'
>>
>>
>> Hope it helps !
>> Best regards,
>>
>> Manuel Siggen
>>
>>
>> ________________________________________*
>> Manuel Siggen* - Ingénieur de développement logiciel
>> Etat de Vaud, Département des Infrastructures et des Ressources Humaines
>> (DIRH)
>> Direction des Systèmes d'Information (DSI)
>> Pôle Référentiels
>> Avenue de Longemalle 1, CH-1020 Renens
>> Tel:+41 (0)21 316 26 43 Fax:+41 (0)21 316 27 26 *
>> **manuel.siggen@vd.ch* <manuel.siggen@vd.ch> - *www.vd.ch*<http://www.vd.ch/>
>>
>>
>>
>> De : Aleksei Valikov <valikov_at_gmx.net>
>> A : Rogier Enders <rogier.enders_at_gmail.com>
>> Cc : "users_at_jaxb.java.net" <users_at_jaxb.java.net>
>> Date : 15.08.2013 08:09
>> Objet : Re: Bug or not: trying to use seperate schema compilation
>> using maven-jaxb2-plugin
>> Envoyé par : aleksei.valikov_at_gmail.com
>> ------------------------------
>>
>>
>>
>> Hi Rogier,
>>
>> I think, your reasoning is quite correct. To note, this is not a bug
>> in the maven-jaxb2-plugin, it is more a problem with XJC itself.
>> maven-jaxb2-plugin only wraps XJC.
>>
>> I'm also coming over this issue time after time. I always managed to
>> resolve it somehow, but I can't formulate the method at the moment.
>> Would you please put a sample demo project together - I'll look into
>> it. We'll probably have to file an issue for XJC since I don't think
>> this can be fixed in the Maven plugin.
>>
>> Bye,
>> /lexi
>>
>>
>> On Wed, Aug 14, 2013 at 3:33 PM, Rogier Enders <rogier.enders_at_gmail.com>
>> wrote:
>> > Hi Valikov,
>> >
>> > I'm trying to generate sources from a set of xml schemas using the
>> > "maven-jaxb2-plugin" version 0.8.3.
>> >
>> > The schemas refer to each other using an import with a namespace and a
>> > schemaLocation attibute. The schemaLocation attribute is relative.
>> >
>> > Using a catalog file (in XML format, Oasis Catalog standard version 1.1)
>> I
>> > managed to change the schemaLocation using a systemSuffix to an uri
>> > reference resource inside a Maven artifact.
>> >
>> > First: schema A sources are generated using the plugin without any
>> > configuration. The jar is uploaded to the maven repository.
>> >
>> > Schema B sources are generated using the pluging. The A.jar is defined
>> as a
>> > dependency and useDependenciesAsEpisode is set to true. There is also a
>> > catalog parameter with a systemSuffix. This jar is also uploaded to the
>> > maven repository.
>> >
>> > All works well for schema B which imports schema A with a relative
>> > schemaLocation, using episodes.
>> >
>> > Now I'm trying to generate sources for a schema C which import B and A.
>> This
>> > results in the following error:
>> > "[ERROR] Error while parsing schema(s).Location [
>> >
>> jar:file:/home/rogier/.m2/repository/nl/renders/address-rel/1.0/address-rel-1.0.jar!/address.xsd{9,13}].
>> > org.xml.sax.SAXParseException: 'address' is already defined"
>> >
>> > It seams like the plugin is generating sources for schema C, since this
>> > schema imports B and A, sources are also generated for these schemas but
>> > since B imports A, it tries to generate another set of sources for
>> schema A
>> > which results in the error "is already defined".
>> >
>> > If I remove the schemaLocation attrinute from the XSD schema in the
>> > generated B.jar, it works well since the sources from schema A are only
>> > generated once.
>> >
>> > Is this a bug in the plugin or am I missing something here? If you like I
>> > can send to some sources to reproduce the problem.
>> >
>> > With regards,
>> >
>> > Rogier Enders
>>
>>