Actually, answering my own question, I found the answer in the spec (7.6.1):
*map* if specified, prevents the classes from being generated from this
schema. When the value is "0" or "false", then no class/interface/enum will
be generated from this package. map defaults to true.
So that flag is what actually makes the episode work - without it, all
classes will be generated on each compilation, which is precisely what the
episode is designed to prevent (hence the fact that it's always set in the
plugin).
Cheers,
Colin
2008/6/6 Colin Fleming <colin.mailinglist_at_gmail.com>:
> Hi Lexi,
>
> Thanks very much for the quick response. Do you know what that flag
> actually does? Looking at the code for the episode plugin, that flag is
> always set. Is how it works documented anywhere? Additionally, if that flag
> really causes the behaviour you describe, why does the second example in my
> issue work when core is still imported and used extensively?
>
> I actually just tried my example that's currently failing in two branches
> of our project. The code was branched very recently, and all code related to
> JAXB is identical. The code works in one and fails in the other - both with
> the same episode files. Essentially we've found this problem to simply be
> extremely sensitive - changing some random apparently unrelated thing causes
> it to work or break.
>
> Any more ideas as to what might be happening or what I might be able to do
> to work around it?
>
> Thanks again,
> Colin
>
> 2008/6/6 Aleksei Valikov <valikov_at_gmx.net>:
>
> Hi.
>>
>> > I've had a problem reported in the JAXB issue tracker
>> > (https://jaxb.dev.java.net/issues/show_bug.cgi?id=484) for a while now,
>> but
>> > in desperation I'm posting here as well. I finally managed to isolate a
>> test
>> > case, see the files in the tar attached to the issue. The problem is the
>> > javaType customisation on core:ID (in core.xsd).
>> >
>> > We have a large project where the data layer is almost totally based on
>> > JAXB. We have multiple levels of schemas, and use xs:import and
>> extensions
>> > heavily. Occasionally we have a problem where JAXB will refuse to run,
>> > saying that it cannot honour a customisation, usually from a base schema
>> > when compiling a sub-schema.
>> >
>> > To reproduce:
>> >
>> > xjc.sh core.xsd -d output -p
>> > generated.core.com.mycorp.model.common.datatypes
>> >
>> > This compiles just the base schema, and works correctly.
>> >
>> > xjc.sh core.xsd card.xsd -extension -b core.episode -d output -p
>> > generated.card.com.mycorp.model.common.datatypes
>> >
>> > This demonstrates the base file being imported with the corresponding
>> > episode. This also works.
>> >
>> > xjc.sh core.xsd iso8583.xsd testcase.xsd -extension -b core.episode -b
>> > iso8583.episode -d output -p
>> > generated.testcase.com.mycorp.model.common.datatypes
>> >
>> > This case should be identical to the above, but breaks with the error
>> below:
>> >
>> > [ERROR] compiler was unable to honor this javaType customization. It is
>> > attached to a wrong place, or its inconsistent with other bindings.
>> > line 66 of file:/Users/colin/dev/platform/common/testcase/core.xsd
>> >
>> > [ERROR] (the above customization is attached to the following location
>> in
>> > the schema)
>> > line 61 of file:/Users/colin/dev/platform/common/testcase/core.xsd
>> >
>> > So the same file (core.xsd) works in some situations, but not in others.
>> > This is what we've seen - very minor (apparently trivial) changes can
>> break
>> > our compilation, usually at the worst moments, of course. It normally
>> > happens with imports, but not always. We're doing some fairly funky
>> stuff
>> > with JAXB - we call it directly from Java and use plugins heavily - and
>> this
>> > seems to break more frequently than the command line tool, but the above
>> > example breaks consistently with 2.1.5, 2.1.6 and 2.1.7 on the command
>> line.
>> >
>> > This happens to us very frequently, but is very difficult to reproduce,
>> and
>> > is becoming a show-stopping bug - we'll have to look at implementing our
>> own
>> > mapping layer shortly unless we can solve this. Has anyone seen anything
>> > like this? I'd love to be shown to be doing something stupid at this
>> > point...
>> >
>> > Thanks for any help,
>>
>> Your sample starts working if I remove <schemaBindings map="false"/>
>> from the core.episode file.
>> I believe that if the namespace is not mapped, simple type
>> customizations are not processed therefore XJC complains about
>> javaType.
>> Hope this helps.
>>
>> Bye.
>> /lexi
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>>
>>
>