Do we have all of the circumstantial evidence now?
I can't try it due to lack of C.xsd, but I suspect that if you compile
A.xsd, B.xsd, C.xsd, D.xsd in one fell swoop, it should be OK, and, if
packages are kept asunder, you should be able to deploy only what customers
B, C, BC or BCD need. Of course, you could deploy all of the generated
classes to in any case - it's probably not a giveaway.
If all of the above isn't feasible, then I think you'll have to consider a
rework of the XML Schema files, avoiding the ref of an XML element.
Consider using type extension: this will also enable you to have
definitions in one place.
Cheers
Wolfgang
On 17 May 2015 at 13:28, Alexander SCHULZ <alexander.schulz_at_soprasteria.com>
wrote:
> Thank you for the very quick reply!
>
>
>
> Most of our customers are using more than one project/product. For us,
> these projects (A-D) are modules of our application. So one or more modules
> run together in one deployment unit. When there are more than one module of
> B,C or D in one deployment unit (war) the jaxb initialisation error will
> raise again because of QName duplications.
>
>
>
> Alex
>
> *Von:* Wolfgang Laun [mailto:wolfgang.laun_at_gmail.com]
> *Gesendet:* Sonntag, 17. Mai 2015 12:54
> *An:* users_at_jaxb.java.net
> *Betreff:* Re: Duplicate QName in ObjectFactory when using episode
>
>
>
> Hi Alexander,
>
>
> I'll have to have a closer look at the episode issue, but now that I see
> the xsd files I'd propose to leave the episode function aside and simply
> build B, C and D with a reference to A.xsd, wherever it is at home. (Or, as
> it seems from the .zip, from a copy in B, C and D sources. True, this will
> generate the classes for A.xsd three times, but this isn't costly. You'll
> can deploy three projects, each with its own set of class files resulting
> from A.xsd. Or, if you want to, generate A alone, and include the resulting
> class files as a jar of their own but omit the class files resulting from
> the builds of B, C, D. This is merely a CM issue.
>
> Cheers
>
> Wolfgang
>
>
>
> On 17 May 2015 at 12:24, Alexander SCHULZ <
> alexander.schulz_at_soprasteria.com> wrote:
>
> Hi Wolfgang,
>
>
>
> you find two very simple maven projects attached. The first one is called
> "reduced-A" which is an equivalent to "Project A", and a second one called
> "reduced-B" which is equivalent to "Project B". reduced-B uses reduced-A as
> episode.
>
>
>
> After building A and B you will find these two ObjectFactorys generated:
>
> A:
>
> ...
>
> public class ObjectFactory {
>
> private final static QName _Msg_QNAME = new QName("http://abc/1.0/A",
> "msg");
>
> private final static QName _MessageTypeMetadata_QNAME = new QName("
> http://abc/1.0/A", "metadata");
>
> ...
>
>
>
> B:
>
> ...
>
> public class ObjectFactory {
>
> private final static QName _Msg_QNAME = new QName("http://abc/1.0/A",
> "msg");
>
> ...
>
>
>
> The problem is the identical QName entry "_Msg_QNAME".
>
>
>
> Alex
>
>
>
> *Von:* Wolfgang Laun [mailto:wolfgang.laun_at_gmail.com]
> *Gesendet:* Sonntag, 17. Mai 2015 09:14
> *An:* users_at_jaxb.java.net
> *Betreff:* Re: Duplicate QName in ObjectFactory when using episode
>
>
>
> This can't be resolved without reduced (!) code for the XML Schema files
> for A and B demonstrating the effect.
>
> -W
>
>
>
> On 17 May 2015 at 08:48, Alexander SCHULZ <
> alexander.schulz_at_soprasteria.com> wrote:
>
> Hi John,
>
>
>
> thanks for the quick reply.
>
>
>
> Our product has several modules. In this case project A is some kind of
> base module which is used by project B,C and D. Projects B,C and D have own
> live cycles and can be separately deployed together with A. So we can't
> combine A with another project. I thought that episodes will just do that.
>
>
>
> Alex
>
>
>
> *Von:* John MacAuley [mailto:john_at_blackacorn.ca]
> *Gesendet:* Samstag, 16. Mai 2015 19:11
> *An:* users_at_jaxb.java.net
> *Betreff:* Re: Duplicate QName in ObjectFactory when using episode
>
>
>
> Alexander,
>
>
>
> Why not create a separate jar containing the xjc generated objects from
> the schema of both projects A and B then use this common jar in both
> projects? This would probably be the easiest fix.
>
>
>
> John
>
>
>
> On 2015-05-16, at 12:42 PM, Alexander SCHULZ <
> alexander.schulz_at_soprasteria.com> wrote:
>
>
>
> Hello,
>
>
>
> I have a problem with JAXB generated ObjectFactory. The situation is as
> follows:
>
>
>
> I have a "project A" with some object mappings generated by xjc from a
> schema. I declared it as episode, so an episode description file is
> generated.
>
>
>
> There is a second "project B" which uses project A and also generates
> Mapping from its own schema. The schema of project B references the schema
> of project A. xjc uses the episodes mechanism and uses the classes from
> project A. So far so good.
>
>
>
> At runtime, when jaxb initializes, an exception is raised because of
> duplicate QName entries. Some of the classes from project A, which have
> QName entries in the ObjectFactory of project A, also have a QName entry in
> the ObjectFactory of project B, but the classes are not generated a second
> time.
>
>
>
> Please can you give me a hint whats wrong.
>
>
>
> Thank you very much!
>
>
>
> Mit freundlichen Grüßen
>
>
> * Alexander SCHULZ*
>
> Manager, Utilities
>
> *<image002.png>*
>
> Sopra Steria GmbH
> Friedrichstraße 148
> 10117 Berlin - Deutschland
> Phone: +49 30 206188-7274 - Mobile: 0160 7418482
> alexander.schulz_at_soprasteria.com - www.soprasteria.de
>
> Before printing, think about the environment.
> The content of this message may be confidential, legally privileged and
> protected by law. Unauthorized use, copying or disclosure of any of it may
> be unlawful. If you are not the intended recipient please notify the sender
> and remove it from your system. While attachments to this e-mail are
> checked for viruses, we do not accept any liability for any damage
> sustained by viruses.
>
>
>
> Sopra Steria Consulting is the trading name of the following companies:
> (i) Sopra Steria GmbH - Vorsitzender des Aufsichtsrates: François Enaud -
> Geschäftsführer: Urs Michael Krämer - Sitz der Gesellschaft: Hamburg - HR B
> 130165 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351
> (ii) Sopra Group GmbH - Geschäftsführer: Xavier Pecquet - Sitz der
> Gesellschaft: Frankfurt am Main - HR B 79327 Amtsgericht Frankfurt am Main
> - USt-ID-Nr.: DE148265247
>
>
>
> Sopra Steria Consulting is the trading name of the following companies:
> (i) Sopra Steria GmbH - Vorsitzender des Aufsichtsrates: François Enaud -
> Geschäftsführer: Urs Michael Krämer - Sitz der Gesellschaft: Hamburg - HR B
> 130165 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351
> (ii) Sopra Group GmbH - Geschäftsführer: Xavier Pecquet - Sitz der
> Gesellschaft: Frankfurt am Main - HR B 79327 Amtsgericht Frankfurt am Main
> - USt-ID-Nr.: DE148265247
>
>
>
> Sopra Steria Consulting is the trading name of the following companies:
> (i) Sopra Steria GmbH - Vorsitzender des Aufsichtsrates: François Enaud -
> Geschäftsführer: Urs Michael Krämer - Sitz der Gesellschaft: Hamburg - HR B
> 130165 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351
> (ii) Sopra Group GmbH - Geschäftsführer: Xavier Pecquet - Sitz der
> Gesellschaft: Frankfurt am Main - HR B 79327 Amtsgericht Frankfurt am Main
> - USt-ID-Nr.: DE148265247
>
>
> Sopra Steria Consulting is the trading name of the following companies:
> (i) Sopra Steria GmbH - Vorsitzender des Aufsichtsrates: François Enaud -
> Geschäftsführer: Urs Michael Krämer - Sitz der Gesellschaft: Hamburg - HR B
> 130165 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351
> (ii) Sopra Group GmbH - Geschäftsführer: Xavier Pecquet - Sitz der
> Gesellschaft: Frankfurt am Main - HR B 79327 Amtsgericht Frankfurt am Main
> - USt-ID-Nr.: DE148265247
>