JAXB - Creating modules for reuse
Asked Answered
S

2

8

Does JAXB support modular code generation?

Most of my background is with JibX for XML marshalling, but for legacy reasons our firm is using JAXB.

One feature that was available for JIBX was modular code generation. Say I have a main schema but I have several different envelopes for that schema. With JibX I could create a jar file out of the JibX'ed core schema, and then in separate projects I could JibX my envelope schemas and simply point to the shared jar instead of having to duplicate the code generation of the core schemas for each envelope.

I don't yet see a way for JAXB to handle this - has anyone been successful doing something like this?

Thanks in advance, Roy

Sudor answered 3/5, 2011 at 12:38 Comment(0)
C
10

For the JAXB RI, that's handled with "episode" files (these are really just customization files). Process the core schema first, making sure to have xjc use the -episode <file> arg. Package the results of that processing into a JAR file with the episode file in META-INF/sun-jaxb.episode. Then, pass that JAR file as an arg to xjc when processing the other schemas.

Cordiality answered 3/5, 2011 at 16:30 Comment(2)
+1 - Here is an example of using episode files: weblogs.java.net/blog/kohsuke/archive/2006/09/…Church
bdoughans link no longer works, but here's it from web archive: web.archive.org/web/20080328004411/http://weblogs.java.net/blog/…Establishmentarian
C
4

Using a JAXB 2.1 implementation (Metro, EclipseLink MOXy, Apache JaxMe, etc), you can specify that schema types correspond to existing classes in order to prevent them from being generated.

For example:

root.xsd

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/root">
    <xsd:import schemaLocation="imported.xsd" namespace="http://www.example.com/imported"/>
    <xsd:complexType name="root">
        <xsd:attribute name="root-prop" type="xsd:string"/>
    </xsd:complexType>
</xsd:schema>

imported.xsd

<?xml version="1.0"?>
<xsd:schema 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns="http://www.example.com/imported" 
    targetNamespace="http://www.example.com/imported">
    <xsd:complexType name="imported">
        <xsd:attribute name="imported-prop" type="xsd:string"/>
    </xsd:complexType>
</xsd:schema>

Problem Statement

If you use the XJC tool to generate java classes from the XML schema:

xjc -d out root.xsd

You the following is generated:

com\example\imported\Imported.java
com\example\imported\ObjectFactory.java
com\example\imported\package-info.java
com\example\root\ObjectFactory.java
com\example\root\Root.java
com\example\root\package-info.java

imported-bindings.xml

You can use a JAXB bindings file to specify that types from imported.xsd point to existing classes:

<jxb:bindings 
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
    version="2.1">

    <jxb:bindings schemaLocation="imported.xsd">
            <jxb:bindings node="//xs:complexType[@name='imported']">
                <jxb:class ref="com.example.imported.Imported"/>
            </jxb:bindings>
    </jxb:bindings>
</jxb:bindings>

Running the XJC

Now if we run XJC with out bindings file:

xjc -d out -b imported-bindings.xml root.xsd

None of the files specified in the bindings file will be generated:

com\example\root\ObjectFactory.java
com\example\root\Root.java
com\example\root\package-info.java

Alternative Approach

The code generated from the imported schema directly (xjc imported.xsd) and indirectly (xjc root.xsd) is the same. You can simply drop the code generated indirectly and point at the project containing the code that was generated directly.

Church answered 3/5, 2011 at 14:4 Comment(1)
While the bindings file approach does work to suppress generation of complextypes from imported schema, it seems to fail for simpletypes. See: #16816298Bestraddle

© 2022 - 2024 — McMap. All rights reserved.