Going further with customizations

The Example 2 customizations showed some basic modifications to CodeGen default behavior. The third example goes further, using custom2.xml:

<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"/>
  <class-decorator class="org.jibx.schema.codegen.extend.CollectionMethodsDecorator"/>
  <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="PricedItineraryType">
      <element path="**" name="AirItinerary" ignore="true"/>
      <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 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>

These customizations effect both the form of the generated code and the actual schema structure used to drive the code and binding generation. The package attribute on the root schema-set element tells CodeGen to use a particular Java package for the generated code. The type-substitutions attribute gives pairs of types, with the second type in each pair substituted for the first wherever referenced in the schema definitions. The name-converter element configures the CodeGen name handling, in this case stripping some leading and trailing text from XML names before they're converted to Java names. The class-decorator element adds some useful support methods for each collection value in the generated classes.

The rest of the customizations dig down into specific schema definitions and eliminate unneeded components, either by specifically including or excluding particular type definitions from a schema (via includes and excludes attributes on schema elements) or by telling CodeGen to ignore specific elements embedded within a schema definition. The ignored elements will be accepted when unmarshalling XML documents but their content will not be processed, and they will never be generated when marshalling XML documents.

Generated code

Run the 'custgen2' target and see the gen/src directory. You can also use the 'custom2' target to generate and compile the code, run the binding compiler, and finally run a supplied test program which roundtrips the sample documents from the samples directory. The number of generated classes is now much smaller than in the first example, since the customizations have eliminated many different schema components which are not used in the sample documents. The generated class names have also been simplified by eliminating the repetitive name suffixes used in the schemas, and usage has been improved by replacing java.math.BigDecimal and java.math.BigInteger references with java.lang.Float and java.lang.Integer references, respectively.

TODO: add discussion