Links: Table of Contents | Single HTML | Single PDF

Tools

1. XJC

1.1. xjc Overview

JAXB RI also provides an Ant task to run the binding complier - see the instructions for XJC Ant Task.

1.2. Launching xjc

The binding compiler can be launched using the appropriate xjc shell script in the bin directory for your platform.

  • Solaris/Linux

    % /path/to/jaxb/bin/xjc.sh -help
  • Windows

    > c:\path\to\jaxb\bin\xjc.bat -help

1.2.1. Execute the jaxb-xjc.jar JAR File

If all else fails, you should be able to execute the jaxb-xjc.jar file:

  • Solaris/Linux

    % java -jar $JAXB_HOME/lib/jaxb-xjc.jar -help
  • Windows

    > java -jar %JAXB_HOME%\lib\jaxb-xjc.jar -help

This is equivalent of running xjc.sh or xjc.bat, and it allows you to set the JVM parameters.

1.3. xjc Syntax

xjc [OPTION]... <schema file/URL/dir/jar> [-b <binding>...]

Usage: xjc [-options ...] <schema file/URL/dir/jar> ... [-b <bindinfo>] ...
If dir is specified, all schema files in it will be compiled.
If jar is specified, /META-INF/sun-jaxb.episode binding file will be compiled.
Options:
  -nv                :  do not perform strict validation of the input schema(s)
  -extension         :  allow vendor extensions - do not strictly follow the
                        Compatibility Rules and App E.2 from the JAXB Spec
  -b <file/dir>      :  specify external bindings files (each <file> must have its own -b)
                        If a directory is given, **/*.xjb is searched
  -d <dir>           :  generated files will go into this directory
  -p <pkg>           :  specifies the target package
  -httpproxy <proxy> :  set HTTP/HTTPS proxy. Format is [user[:password]@]proxyHost:proxyPort
  -httpproxyfile <f> :  Works like -httpproxy but takes the argument in a file to protect password 
  -classpath <arg>   :  specify where to find user class files
  -catalog <file>    :  specify catalog files to resolve external entity references
                        support TR9401, XCatalog, and OASIS XML Catalog format.
  -readOnly          :  generated files will be in read-only mode
  -npa               :  suppress generation of package level annotations (**/package-info.java)
  -no-header         :  suppress generation of a file header with timestamp
  -target (2.0|2.1)  :  behave like XJC 2.0 or 2.1 and generate code that doesn't use any 2.2 features.
  -encoding <encoding> :  specify character encoding for generated source files
  -enableIntrospection :  enable correct generation of Boolean getters/setters to enable Bean Introspection apis 
  -disableXmlSecurity  :  disables XML security features when parsing XML documents 
  -contentForWildcard  :  generates content property for types with multiple xs:any derived elements 
  -xmlschema         :  treat input as W3C XML Schema (default)
  -relaxng           :  treat input as RELAX NG (experimental,unsupported)
  -relaxng-compact   :  treat input as RELAX NG compact syntax (experimental,unsupported)
  -dtd               :  treat input as XML DTD (experimental,unsupported)
  -wsdl              :  treat input as WSDL and compile schemas inside it (experimental,unsupported)
  -verbose           :  be extra verbose
  -quiet             :  suppress compiler output
  -help              :  display this help message
  -version           :  display version information
  -fullversion       :  display full version information

Extensions:
  -Xinject-code      :  inject specified Java code fragments into the generated code
  -Xlocator          :  enable source location support for generated code
  -Xsync-methods     :  generate accessor methods with the 'synchronized' keyword
  -mark-generated    :  mark the generated code as @javax.annotation.Generated
  -episode           :  generate the episode file for separate compilation
  -Xpropertyaccessors :  Use XmlAccessType PROPERTY instead of FIELD for generated classes

1.3.1. Summary of Command Line Options

-nv

By default, the XJC binding compiler performs strict validation of the source schema before processing it. Use this option to disable strict schema validation. This does not mean that the binding compiler will not perform any validation, it simply means that it will perform less-strict validation.

-extension

By default, the XJC binding compiler strictly enforces the rules outlined in the Compatibility chapter of the JAXB Specification. Appendix E.2 defines a set of W3C XML Schema features that are not completely supported by JAXB v1.0. In some cases, you may be allowed to use them in the "-extension" mode enabled by this switch. In the default (strict) mode, you are also limited to using only the binding customizations defined in the specification. By using the "-extension" switch, you will be allowed to use the Overview.

-b <file>

Specify one or more external binding files to process. (Each binding file must have it's own -b switch.) The syntax of the external binding files is extremely flexible. You may have a single binding file that contains customizations for multiple schemas or you can break the customizations into multiple bindings files:

xjc schema1.xsd schema2.xsd schema3.xsd -b bindings123.xjb
xjc schema1.xsd schema2.xsd schema3.xsd -b bindings1.xjb -b bindings2.xjb -b bindings3.xjb

In addition, the ordering of the schema files and binding files on the command line does not matter.

-d <dir>

By default, the XJC binding compiler will generate the Java content classes in the current directory. Use this option to specify an alternate output directory. The output directory must already exist, the XJC binding compiler will not create it for you.

-encoding <encoding>

Set the encoding name for generated sources, such as EUC-JP or UTF-8. If -encoding is not specified, the platform default encoding is used.

-p <pkg>

Specifying a target package via this command-line option overrides any binding customization for package name and the default package name algorithm defined in the specification.

-httpproxy <proxy>

Specify the HTTP/HTTPS proxy. The format is [user[:password]@]proxyHost[:proxyPort]. The old -host and -port are still supported by the RI for backwards compatibility, but they have been deprecated.

-httpproxyfile <f>

Same as the -httpproxy <proxy> option, but it takes the <proxy> parameter in a file, so that you can protect the password (passing a password in the argument list is not safe.)

-classpath <arg>

Specify where to find client application class files used by the <jxb:javaType> and <xjc:superClass> customizations.

-catalog <file>

Specify catalog files to resolve external entity references. Supports TR9401, XCatalog, and OASIS XML Catalog format. Please read the XML Entity and URI Resolvers document or the catalog-resolver sample application.

-readOnly

By default, the XJC binding compiler does not write-protect the Java source files it generates. Use this option to force the XJC binding compiler to mark the generated Java sources read-only.

-npa

Supress the generation of package level annotations into **/package-info.java. Using this switch causes the generated code to internalize those annotations into the other generated classes.

-no-header

Supress the generation of a file header comment that includes some note and timestamp. Using this makes the generated code more diff-friendly.

-target 2.0

Avoid generating code that relies on any JAXB 2.1 features. This will allow the generated code to run with JAXB 2.0 runtime (such as JavaSE 6.)

-xmlschema

treat input schemas as W3C XML Schema (default). If you do not specify this switch, your input schemas will be treated as W3C XML Schema.

-relaxng

Treat input schemas as RELAX NG (experimental, unsupported). Support for RELAX NG schemas is provided as a Overview.

-relaxng-compact

Treat input schemas as RELAX NG compact syntax(experimental, unsupported). Support for RELAX NG schemas is provided as a Overview.

-dtd

Treat input schemas as XML DTD (experimental, unsupported). Support for RELAX NG schemas is provided as a Overview.

-wsdl

Treat input as WSDL and compile schemas inside it (experimental,unsupported).

-quiet

Suppress compiler output, such as progress information and warnings..

-verbose

Be extra verbose, such as printing informational messages or displaying stack traces upon some errors..

-help

Display a brief summary of the compiler switches.

-version

Display the compiler version information.

<schema file/URL/dir>

Specify one or more schema files to compile. If you specify a directory, then xjc will scan it for all schema files and compile them.

-Xlocator

This feature causes the generated code to expose SAX Locator information about the source XML in the Java bean instances after unmarshalling.

-Xsync-methods

This feature causes all of the generated method signatures to include the synchronized keyword.

-mark-generated

This feature causes all of the generated code to have @Generated annotation.

-episode <FILE>

Generate an episode file from this compilation, so that other schemas that rely on this schema can be compiled later and rely on classes that are generated from this compilation. The generated episode file is really just a JAXB customization file (but with vendor extensions.)

-Xinject-code

Inject specified Java code fragments into the generated code; see here for more details.

-Xpropertyaccessors>

Annotate the @XmlAccessorType of generated classes with XmlAccessType PROPERTY instead of FIELD

1.3.2. Summary of Deprecated and Removed Command Line Options

-host & -port

These options have been deprecated and replaced with the -httpproxy option. For backwards compatibility, we will continue to support these options, but they will no longer be documented and may be removed from future releases.

-use-runtime

Since the JAXB 2.0 specification has defined a portable runtime, it is no longer necessary for the JAXB RI to generate **/impl/runtime packages. Therefore, this switch is obsolete and has been removed.

-source

The -source compatibility switch was introduced in the first JAXB 2.0 Early Access release for convenience reasons. You shall not rely on this switch, because it might get removed from any future release of JAXB 2.0. If you need to generate 1.0.x code, please use an installation of the 1.0.x codebase.

1.4. Compiler Restrictions

In general, it is safest to compile all related schemas as a single unit with the same binding compiler switches.

Please keep the following list of restrictions in mind when running xjc. Most of these issues only apply when compiling multiple schemas with multiple invocations of xjc.

  • To compile multiple schemas at the same time, keep the following precedence rules for the target Java package name in mind:

    1. The -p command line option takes the highest precedence.

    2. <jaxb:package> customization

    3. If targetNamespace is declared, apply targetNamespace -> Java package name algorithm defined in the specification.

    4. If no targetNamespace is declared, use a hardcoded package named "generated".

  • It is not legal to have more than one < jaxb:schemaBindings> per namespace, so it is impossible to have two schemas in the same target namespace compiled into different Java packages.

  • All schemas being compiled into the same Java package must be submitted to the XJC binding compiler at the same time - they cannot be compiled independently and work as expected.

  • Element substitution groups spread across multiple schema files must be compiled at the same time.

1.5. Generated Resource Files

XJC produces a set of packages containing Java source files and also jaxb.properties files, depending on the binding options you used for compilation. When generated, jaxb.properties files must be kept with the compiled source code and made available on the runtime classpath of your client applications:

2. XJC Ant Task

2.1. xjc Task Overview

The jaxb-xjc.jar file contains the XJCTask.class file, which allows the XJC binding compiler to be invoked from the Ant build tool. To use XJCTask, include the following statement in your build.xml file:

<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
    <classpath>
        <fileset dir="path/to/jaxb/lib" includes="*.jar"/>
    </classpath>
</taskdef>

This maps XJCTask to an Ant task named xjc. For detailed examples of using this task, refer to any of the build.xml files used by the Sample Apps.

2.2. xjc Task Attributes

2.2.1. Environment Variables

  • ANT_OPTS - command-line arguments that should be passed to the JVM. For example, you can define system properties or set the maximum Java heap size here.

2.2.2. Parameter Attributes

xjc supports the following parameter attributes.

AttributeDescriptionRequired

schema

A schema file to be compiled. A file name (can be relative to the build script base directory), or an URL.

This or nested < schema> elements are required.

binding

An external binding file that will be applied to the schema file.

No

package

If specified, generated code will be placed under this Java package. This option is equivalent to the "-p" command-line switch.

No

destdir

Generated code will be written under this directory. If you specify destdir="abc/def" and package="org.acme", then files are generated to abc/def/org/acme.

Yes

encoding

Set the encoding name for generated sources, such as EUC-JP or UTF-8. If it is not specified, the platform default encoding is used.

No

readonly

Generate Java source files in the read-only mode if true is specified. false by default.

No

header

Generate a header in each generated file indicating that this file is generated by such and such version of JAXB RI when. true by default.

No

extension

If set to true, the XJC binding compiler will run in the extension mode. Otherwise, it will run in the strict conformance mode. Equivalent of the " -extension" command line switch. The default is false.

No

catalog

Specify the catalog file to resolve external entity references. Support TR9401, XCatalog, and OASIS XML Catalog format. See the catalog-resolver sample for details.

No

removeOldOutput

Used in pair with nested <produces> elements. When this attribute is specified as " yes", the files pointed to by the <produces> elements will be all deleted before the XJC binding compiler recompiles the source files. See the up-to-date check section for details.

No

source

Specify which version of the schema compiler to use. Must be either "1.0", "2.0", or "2.1". The compiler will parse XML Schema and bind them according to the rules specified by the given version of the specification. Note that 2.1 is backward compatible with 2.0, so these two flags won't make any difference. You shall not rely on this attribute, because it might get removed from any future version of JAXB. For generating 1.0.x code, please use an installation of the 1.0.x codebase.

No, defaults to "2.1"

target

Specifies the runtime environment in which the generated code is supposed to run. This value must be smaller than the source attribute, if specified (IOW, you can't do source="1.0" target="2.0") This allows more up-to-date versions of XJC to be used for developing applications that run on earlier JAXB versions.

No, defaults to "2.1"

language

Specifies the schema language to compile. Supported values are "WSDL", "XMLSCHEMA", and "WSDL." Case insensitive.

No, defaults to "XMLSCHEMA"

2.2.3. Nested Elements

xjc supports the following nested element parameters.

2.2.3.1. schema

To compile more than one schema at the same time, use a nested <schema> element, which has the same syntax as <fileset> .

2.2.3.2. binding

To specify more than one external binding file at the same time, use a nested <binding> element, which has the same syntax as <fileset> .

2.2.3.3. classpath

To specify locations of the user-defined classes necessary during the compilation (such as an user-defined type that is used through a <javaType> customization), use nested <classpath> elements. For the syntax, see "path-like structure" .

2.2.3.4. arg

Additional command line arguments passed to the XJC. For details about the syntax, see the relevant section in the Ant manual. This nested element can be used to specify various options not natively supported in the xjc Ant task. For example, currently there is no native support for the following xjc command-line options:

  • -nv

  • -use-runtime

  • -schema

  • -dtd

  • -relaxng

  • -Xlocator

  • -Xsync-methods

To use any of these features from the <xjc> Ant task, you must specify the appropriate nested < arg> elements.

2.2.3.5. depends

Files specified with this nested element will be taken into account when the XJC task does the up-to-date check. See the up-to-date check section for details. For the syntax, see <fileset> .

2.2.3.6. produces

Files specified with this nested element will be taken into account when the XJC task does the up-to-date check. See the up-to-date check section for details. For the syntax, see <fileset> .

2.2.3.7. xmlcatalog

The xmlcatalog element is used to resolve entities when parsing schema documents.

2.3. Generated Resource Files

Please see the Generated Resource Files for more detail.

2.4. Up-to-date Check

By default, the XJC binding compiler always compiles the inputs. However, with a little additional setting, it can compare timestamps of the input files and output files and skip compilation if the files are up-to-date.

Ideally, the program should be able to find out all the inputs and outputs and compare their timestamps, but this is difficult and time-consuming. So you have to tell the task input files and output files manually by using nested <depends> and <produces> elements. Basically, the XJC binding compiler compares the timestamps specified by the <depends> elements against those of the <produces> set. If any one of the "depends" file has a more recent timestamp than some of the files in the "produces" set, it will compile the inputs. Otherwise it will skip the compilation.

This will allow you to say, for example "if any of the .xsd files in this directory are newer than the .java files in that directory, recompile the schema".

Files specified as the schema files and binding files are automatically added to the "depends" set as well, but if those schemas are including/importing other schemas, you have to use a nested <depends> elements. No files are added to the <produces> set, so you have to add all of them manually.

A change in a schema or an external binding file often results in a Java file that stops being generated. To avoid such an "orphan" file, it is often desirable to isolate all the generated code into a particular package and delete it before compiling a schema. This can be done by using the removeOldOutput attribute. This option allows you to remove all the files that match the "produces" filesets before a compilation. Be careful when you use this option so that you don't delete important files.

2.5. Schema Language Support

This release of the JAXB RI includes experimental support for RELAX NG, DTD, and WSDL. To compile anything other than W3C XML Schema from the xjc Ant task, you must use the nested < arg> element to specify the appropriate command line switch, such as -dtd, -relaxng, or -wsdl. Otherwise, your input schemas will be treated as W3C XML Schema and the binding compiler will fail.

2.6. xjc Examples

Compile myschema.xsd and place the generated files under src/org/acme/foo:

<xjc schema="src/myschema.xsd" destdir="src" package="org.acme.foo"/>

Compile all XML Schema files in the src directory and place the generated files under the appropriate packages in the src directory:

<xjc destdir="src">
    <schema dir="src" includes="*.xsd"/>
</xjc>

Compile all XML Schema files in the src directory together with binding files in the same directory and places the generated files under the appropriate packages in the src directory. This example assumes that binding files contain package customizations. This example doesn't search subdirectories of the src directory to look for schema files.

<xjc destdir="src">
    <schema dir="src" includes="*.xsd"/>
    <binding dir="src" includes="*.xjb"/>
</xjc>

Compile abc.xsd with an up-to-date check. Compilation only happens when abc.xsd is newer than any of the files in the src/org/acme/foo directory (and its impl subdirectory). Files in these two directories will be wiped away before a compilation, so don't add your own code in those directories. Note that the additional mkdir task is necessary because Ant's fileset requires the directory specified by the dir attribute to exist.

<mkdir dir="src/org/acme/foo"/>
<xjc destdir="src" schema="abc.xsd" removeOldOutput="yes"
     package="org.acme.foo">
    <produces dir="src/org/acme/foo" includes="* impl/*"/>
</xjc>

More complicated example of up-to-date check. In this example, we assume that you have a large set of schema documents that reference each other, with DTDs that describe the schema documents. An explicit <depends> is necessary so that when you update one of the DTDs, XJC will recompile your schema. But <depends> don't have to re-specify all the schema files, because you've already done that via <schema>.

<mkdir dir="src/org/acme/foo"/>
<xjc destdir="src" removeOldOutput="yes"
     package="org.acme.foo">
    <schema dir="schema" includes="*.xsd"/>
    <depends dir="schema" includes="*.dtd"/>
    <produces dir="build/generated-src/org/acme/foo"
              includes="**/*"/>
</xjc>

Compile all XML Schema files in the src directory and subdirectories, excluding files named debug.xsd, and place the generated files under the appropriate packages in the src directory. This example also specifies the -nv option, which disables the strict schema correctness checking:

<xjc destdir="src">
    <schema dir="src" includes="**/*.xsd"
            excludes="**/debug.xsd"/>
    <arg value="-nv"/>
</xjc>

If you depend on a proxy server to resolve the location of imported or included schemas (as you might if you're behind a firewall), you need to make the hostname and port number accessible to the JVM hosting ant. Do this by setting the environment variable ANT_OPTS to a string containing the appropriate java options. For example, from DOS:

> set ANT_OPTS=-Dhttp.proxyHost=webcache.east
> set ANT_OPTS=%ANT_OPTS% -Dhttp.proxyPort=8080
> ant

3. SchemaGen

3.1. schemagen Overview

The current schema generator can process either Java source files or class files.

We also provide an Ant task to run the schema generator - see the instructions for SchemaGen Ant Task.

3.2. Launching schemagen

The schema generator can be launched using the appropriate schemagen shell script in the bin directory for your platform.

If your java sources/classes reference other classes, they must be accessable on your system CLASSPATH environment variable, or they need to be given to the tool by using the -classpath/ -cp options. Otherwise you will see errors when generating your schema.

  • Solaris/Linux

    % path/to/jaxb/bin/schemagen.sh Foo.java Bar.java ...
    Note: Writing schema1.xsd
  • Windows

    > path\to\jaxb\bin\schemagen.bat Foo.java Bar.java ...
    Note: Writing schema1.xsd

3.3. schemagen Syntax

schemagen [OPTION]... <java files>

Usage: schemagen [-options ...] <java files> 

Options: 
    -d <path>         :  Specify where to place processor and javac generated class files 
    -cp <path>        :  Specify where to find user specified files  
    -classpath <path> :  Specify where to find user specified files  
    -episode <file>   :  generate episode file for separate compilation
    -version          :  display version information
    -help             :  Display this usage message

3.3.1. Summary of Command Line Options

-episode

Generates the "episode file", which is really just a JAXB customization file (but with vendor extensions specific to the JAXB RI, as of 2.1.) When people develop additional schemas that depend on what this schemagen invocation produces, they can use this episode file to have their generated code refer to your classes.

3.4. Generated Resource Files

The current schema generator simply creates a schema file for each namespace referenced in your Java classes. There is no way to control the name of the generated schema files at this time. Use SchemaGen Ant Task for that purpose.

4. SchemaGen Ant Task

4.1. schemagen Task Overview

The jaxb-xjc.jar file contains the SchemaGenTask.class file, which allows the schema generator to be invoked from the Ant build tool. To use SchemaGenTask, include the following statement in your build.xml file:

<taskdef name="schemagen"
         classname="com.sun.tools.jxc.SchemaGenTask">
    <classpath>
        <fileset dir="path/to/jaxb/lib" includes="*.jar"/>
    </classpath>
</taskdef>

This maps SchemaGenTask to an Ant task named schemagen. For detailed examples of using this task, refer to the build.xml files used by the java to schema Sample Apps.

4.2. schemagen Task Attributes

4.2.1. Environment Variables

  • ANT_OPTS - command-line arguments that should be passed to the JVM. For example, you can define system properties or set the maximum Java heap size here.

4.2.2. Parameter Attributes

schemagen supports most of the attributes defined by the javac task, plus the following parameter attributes.

AttributeDescriptionRequired

destdir

Base directory to place the generated schema files

No

classpath

Works just like the nested <classpath> element

No

episode

If specified, generate an episode file in the specified name. For more about the episode file, see -episode.

No

4.2.3. Nested Elements

xjc supports all the nested elements defined by the javac task, the following nested element parameters.

4.2.3.1. schema

Control the file name of the generated schema. This element takes a mandatory namespace attribute and a mandaotry file attribute. When this element is present, the schema document generated for the specified namespace will be placed in the specified file name.

The file name is interpreted as relative to the destdir attribute. In the absence of the destdir attribute, file names are relative to the project base directory. This element can be specified multiple times.

4.2.3.2. classpath

A path-like structure that represents the classpath. If your Java sources/classes depend on other libraries, they need to be available in the classpath.

4.3. schemagen Examples

Generate schema files from source files in the src dir and place them in the build/schemas directory.

<schemagen srcdir="src" destdir="build/schemas">

Compile a portion of the source tree.

<schemagen destdir="build/schemas">
    <src path="src"/>
    <exclude name="Main.java"/>
</schemagen>

Set schema file names.

<schemagen srcdir="src" destdir="build/schemas">
    <schema namespace="http://myschema.acme.org/common"
            file="myschema-common.xsd"/>
    <schema namespace="http://myschema.acme.org/onion"
            file="myschema-onion.xsd"/>
</schemagen>

5. 3rd Party Tools

5.1. Maven JAXB Plugin

The Maven2 plugin for JAXB2 is hosted at java.net. If you are using Maven, JAXB jars are available in the java.net maven repository.

5.2. JAXB Workshop

JAXB Workshop hosts a collection of visual tools and IDE plugins useful for working with JAXB.

5.3. XJC Plugins

Various people in the community have developed plugins for XJC that you can use today. These plugins allow you to enhance/alter the code generation of XJC in many different ways. See the list of plugins (if you are interested in hosting your plugin here, let us know.)

5.4. RDBMS Persistence

Lexi has developed the HyperJAXB3 project for RDBMS persistence support for the JAXB RI.

Terms of Use; Privacy Policy; Copyright ©2013-2014 (revision 20140418.2d69abc)
 
 
Close
loading
Please Confirm
Close