Splitting and sharing code

Large organizations often have separate teams working with different parts of a large set of schemas. For instance, the full set of OTA schemas include groupings used for air travel, hotels, automobile rentals, cruises, and more. Different teams within a single company may be working with one or more of these groupings. It's often useful to let the teams working with particular portions of the schemas handle their own data models, while still using a common model for the shared portions (so that application code working with the shared portions will be compatible organization-wide, facilitating code reuse and making it easy to combine different projects, when necessary). This localized control of the data model is even more important when the organization is building schemas for data exchange, rather than just using supplied schemas.

CodeGen suports modular code generation to allow organizations flexibility in their use of schema-based data models. With modular code generation, you start by generating one or more self-contained schema subsets. The code and binding generated for each self-contained subset is a base module which can be compiled into class files and bound by the JiBX binding compiler. The bound class files can be kept as loose files, or more commonly assembled into a jar file.

You can then generate other modules extending those already generated, from schemas which build on the previously-generated schemas. The code in the extension modules reference the Java classes and data bindings generated for the base modules. Each separate module can again be compiled and bound by the JiBX binding compiler independently, only needing access to the binding definitions and bound classes (whether loose, or in a jar) of the appropriate base modules.

To demonstrate how modular generation works, this example splits the OTA schema subset used by all the CodeGen examples into two modules. The first module consists of common definitions used across the full range of OTA schemas, and is generated from the OTA_CommonPrefs.xsd, OTA_CommonTypes.xsd, and OTA_SimpleTypes.xsd schemas. The second module consists of the air travel-related definitions, generated from the OTA_AirCommonTypes.xsd, OTA_AirLowFareSearchRQ.xsd, OTA_AirLowFareSearchRS.xsd, and OTA_AirPreferences.xsd schemas.

Common definitions module

Since the code generation is done in two parts there are two separate customizations used. Both customizations are based on the Example 3 customizations. Here's the custom3a.xml customization file, used for the first generation step (common definitions module):

<schema-set prefer-inline="true" package="org.ota.common"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    type-substitutions="xs:integer xs:int xs:decimal xs:float"
    binding-file-name="base-binding.xml">
  <name-converter strip-prefixes="OTA_"
      strip-suffixes="Type AttributeGroup Group Attributes"/>
  <schema-type type-name="dateTime" java-class="org.joda.time.DateTime"
      serializer="org.jibx.runtime.JodaConvert.serializeUTCDateTime"
      deserializer="org.jibx.runtime.JodaConvert.deserializeUTCDateTime"/>
  <schema-type type-name="date" format-name="LocalDate.default"/>
  <schema-type type-name="time" format-name="LocalTime.local"/>
  <schema name="OTA_CommonTypes.xsd" excludes="ConnectionType">
    <complexType name="SourceType">
      <element path="**" name="Position" ignore="true"/>
      <element path="**" name="BookingChannel" ignore="true"/>
    </complexType>
  </schema>
</schema-set>

This custom3a.xml customization only applies to the common definitions, so the portions of the custom2.xml customization which apply to the air travel schemas are removed. The custom2.xml file has an attribute generate-all="false" on the root <schema-set> element, which has been removed from this customization. This change is necessary so that CodeGen will actually generate all the components necessary to represent the common definitions. Alternatively, if you knew you were only going to be using some specified components from the common definitions you could keep the generate-all="false" attribute and just list the components to be generated, as done for Example 3 (and as also done for the second generation step in this modular approach).

The target package used for the generated classes is also different in this customization. The different package is necessary when using modular generation to prevent conflicts when running the JiBX binding compiler, but generally convenient in any case to make it easy to keep classes from different modules separate.

Finally, there's an added binding-file-name="base-binding.xml" attribute on the root <schema-set> element. This attribute gives a name to be used for the generated root binding. It's not necessary to specify a name in this way when using modular generation, but it does help clarify the use of the different generated bindings.

There's one quirk in generating the common definitions as a separate module. The OTA schemas are structured so that only the top-level message schemas (OTA_AirLowFareSearchRQ.xsd and OTA_AirLowFareSearchRS.xsd, in the subset of OTA schemas used for these examples) define a target namespace. All the other schemas function as what are called "chameleon schemas", meaning that they do not define a target namespace directly but instead assume a target namespace when they are included (directly or indirectly) into one of the message schemas.

To generate the common definitions in the OTA namespace another CodeGen parameter needs to be used. This is the "-u" parameter, which tells CodeGen to force a namespace for schemas which do not specify one. Here's the complete Ant target used for generating the common definitions:

<!-- modular generation of common types -->
  <target name="custgen3a" depends="check-runtime,clean">
    
    <echo message="Running base code generation from schema"/>
    <delete quiet="true" dir="${basedir}/gen"/>
    <java classname="org.jibx.schema.codegen.CodeGen" fork="yes"
        classpathref="classpath" failonerror="true">
      <arg value="-t"/>
      <arg value="${basedir}/gen/src"/>
      <arg value="-c"/>
      <arg value="${basedir}/custom3a.xml"/>
      <arg value="-u"/>
      <arg value="http://www.opentravel.org/OTA/2003/05"/>
      <arg value="otasubset/OTA_Common*.xsd"/>
    </java>
    
  </target>

Air travel module

The custom3b.xml customization file is used for the second generation step (air travel module):

<schema-set prefer-inline="true" generate-all="false" package="org.ota.air"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    type-substitutions="xs:integer xs:int xs:decimal xs:float">
  <name-converter strip-prefixes="OTA_"
      strip-suffixes="Type AttributeGroup Group Attributes"/>
  <schema-type type-name="dateTime" java-class="org.joda.time.DateTime"
      serializer="org.jibx.runtime.JodaConvert.serializeUTCDateTime"
      deserializer="org.jibx.runtime.JodaConvert.deserializeUTCDateTime"/>
  <schema-type type-name="date" format-name="LocalDate.default"/>
  <schema-type type-name="time" format-name="LocalTime.local"/>
  <schema name="OTA_AirLowFareSearchRQ.xsd" includes="OTA_AirLowFareSearchRQ">
    <element name="OTA_AirLowFareSearchRQ" class-name="LowFareSearchRequest">
      <element path="**" name="AlternateLocationInfo" ignore="true"/>
      <element path="**" name="SpecificFlightInfo" ignore="true"/>
      <element path="**" name="ProcessingInfo" ignore="true"/>
    </element>
  </schema>
  <schema name="OTA_AirLowFareSearchRS.xsd" includes="OTA_AirLowFareSearchRS">
    <element name="OTA_AirLowFareSearchRS" class-name="LowFareSearchResponse"/>
  </schema>
  <schema name="OTA_AirCommonTypes.xsd">
    <complexType name="FareType">
      <element path="**" name="Taxes" ignore="true"/>
      <element path="**" name="Fees" ignore="true"/>
      <element path="**" name="FareConstruction" ignore="true"/>
      <element path="**" name="UnstructuredFareCalc" ignore="true"/>
    </complexType>
    <complexType name="FareInfoType">
      <element path="**" name="Date" ignore="true"/>
      <element path="**" name="FareInfo" ignore="true"/>
    </complexType>
    <complexType name="PricedItinerariesType">
      <attribute path="**" name="OriginDestinationRefNumber"
          value-name="refNumber"/>
    </complexType>
    <complexType name="PricedItineraryType">
      <element path="**" name="AirItinerary" ignore="true"/>
      <element path="**" name="AirItineraryPricingInfo"
          value-name="pricingInfo"/>
      <element path="**" name="Notes" ignore="true"/>
      <element path="**" name="TicketingInfo" ignore="true"/>
    </complexType>
    <complexType name="AirItineraryPricingInfoType">
      <element path="**" name="PTC_FareBreakdowns" ignore="true"/>
    </complexType>
    <complexType name="TravelerInformationType">
      <element path="**" name="AirTraveler" ignore="true"/>
    </complexType>
    <complexType name="TravelerInfoSummaryType">
      <element path="**" name="PriceRequestInformation" ignore="true"/>
    </complexType>
  </schema>
  <schema name="OTA_AirPreferences.xsd">
    <complexType name="AirSearchPrefsType">
      <element path="**" name="VendorPref" ignore="true"/>
      <element path="**" name="FlightTypePref" ignore="true"/>
      <element path="**" name="EquipPref" ignore="true"/>
      <element path="**" name="CabinPref" ignore="true"/>
      <element path="**" name="TicketDistribPref" ignore="true"/>
    </complexType>
  </schema>
</schema-set>

This is essentially identical to the custom2.xml file used for Example 3, differing only by missing the reference to the schemas in the common definitions.

CodeGen has to know about the existing modules in order to use them when generating an extension module. This is done by using the "-i" command line parameter to give the paths to the binding definitions for any existing modules. CodeGen will use the supplied binding definitions for any matching schema components, rather than generating new classes and bindings. Here's the complete Ant target used for generating the air travel extension module:

  <target name="custgen3b" depends="check-runtime,check-base,clean-partial">
    
    <echo message="Running extension code generation from schema"/>
    <java classname="org.jibx.schema.codegen.CodeGen" fork="yes"
        failonerror="true">
      <classpath>
        <path refid="classpath"/>
        <pathelement location="${basedir}/base.jar"/>
      </classpath>
      <arg value="-t"/>
      <arg value="${basedir}/gen/src"/>
      <arg value="-i"/>
      <arg value="classpath:base-binding.xml"/>
      <arg value="-c"/>
      <arg value="${basedir}/custom3b.xml"/>
      <arg value="otasubset/OTA_AirLowFareSearch*.xsd"/>
    </java>
    
  </target>

Generated code

First run the 'custgen3a' target and view the common definitions module code in the base/src directory, then run the 'buildbase' target to compile, bind, and jar the common definitions. Once that's done, you can run the 'custgen3b' target and view the air travel module code in the gen/src directory. To compile and bind the air travel module use the 'buildext' target. Finally, you can run the test program to roundtrip the sample documents with the 'runmodular' target. You can also just run the 'modular' target to perform all these steps in sequence.

The generated code is very similar in structure to that from the prior examples, so is not shown here. The main difference is that since all the common definitions were generated separately they're in unique classes and cannot be inlined at the point of use (though there are exceptions - by default, CodeGen always inlines attribute group or group definitions which only contain a single component).

Since all the common definitions are generated as separate classes (except trivial attribute groups and groups) the total number of classes is considerably higher than in the last example: 185 top-level classes and 67 inner classes, for a total of 252, in the common definitions module; plus 7 top-level classes and 26 inner classes, for a total of 33, in the air travel module. This increased number of classes from the last example represents a tradeoff for the convenience of a separate common definitions module.