Package Name | Comment |
com.sun.codemodel | |
com.sun.codemodel.fmt | |
com.sun.codemodel.util | |
com.sun.codemodel.writer | |
com.sun.istack.tools | istack-commons tool time utilities. |
com.sun.org.apache.xml.internal.resolver | |
com.sun.org.apache.xml.internal.resolver.helpers | |
com.sun.org.apache.xml.internal.resolver.readers | |
com.sun.org.apache.xml.internal.resolver.tools | |
com.sun.tools.jxc | |
com.sun.tools.jxc.apt |
APT related code.
This package hosts a driver that runs inside APT for java-to-schema processing,
and additional implementations that deal primarily with APT.
|
com.sun.tools.jxc.gen.config | |
com.sun.tools.jxc.model.nav | |
com.sun.tools.xjc | |
com.sun.tools.xjc.addon.at_generated | |
com.sun.tools.xjc.addon.code_injector | |
com.sun.tools.xjc.addon.episode | |
com.sun.tools.xjc.addon.locator | |
com.sun.tools.xjc.addon.sync | |
com.sun.tools.xjc.api |
API for programatic invocation of XJC and schemagen.
This package provides a way to invoke XJC from within another program.
The primarily target of this API is the JAX-WS RI, but we hope that
this API would be useful for other integration purposes as well.
Getting Started: Using XJC
To invoke XJC, a typical client would do something like this:
SchemaCompiler sc = XJC.createSchemaCompiler();
sc.parseSchema(new InputSource(schema1Url.toExternalForm()));
sc.parseSchema(new InputSource(schema2Url.toExternalForm()));
...
S2JModel model = sc.bind();
The bind operation causes XJC to do the bulk of the work, such as
figuring out what classes to generate, what methods/fields to generate, etc.
The obtained model contains useful introspective information about
how the binding was performed (such as relationship between XML types
and generated Java classes)
Once the model is obtained, generate the code into the file system as follows:
JCodeModel cm = model.generateCode( null, ... );
cm.build(new FileCodeWriter(outputDir));
Implementation Note
This package shouldn't contain any implementation code.
|
com.sun.tools.xjc.api.impl.j2s | |
com.sun.tools.xjc.api.impl.s2j |
implementation of the XJC API for schema to java.
|
com.sun.tools.xjc.api.util |
Utility code shared between JAXB and JAX-WS
|
com.sun.tools.xjc.generator | Code Generator. |
com.sun.tools.xjc.generator.annotation.ri | |
com.sun.tools.xjc.generator.annotation.spec | |
com.sun.tools.xjc.generator.bean | |
com.sun.tools.xjc.generator.bean.field |
FieldRenderer and its implementation classes.
Unless you are deriving from these classes to define your own custom renderer,
you shouldn't be using these classes directly. Use the outline package.
|
com.sun.tools.xjc.generator.util | |
com.sun.tools.xjc.model | Implementation of the
com.sun.xml.bind.v2.model.core package for XJC.
This model is the recipes for the code generation.
It captures the essence of the JAXB-bound beans,
so that the actual Java code can be generated from this object model
mechanically without knowing anything about how the model was built.
Most of the classes/interfaces in this package has one-to-one relationship
with the parameterized core model in the
com.sun.xml.bind.v2.model.core package.
Refer to the core model for better documentation.
The model for XJC also exposes a few additional information on top of the core model.
Those are defined in this package. |
com.sun.tools.xjc.model.nav |
Compile-time representation of Java type system.
These classes are used as TypeT and ClassDeclT of the model parameterization.
This implementaion is designed to be capable of representing pre-existing classes
(such as java.lang.String) as well as the generated classes (represented as JDefinedClass.)
Handling of Primitive Types
Primitive types have two forms (int and Integer), and this complicates the binding process.
For this reason, inside the front end, we always use the boxed types. We'll use the unboxed
form only in the back end when we know the field doesn't need to represent the null value.
|
com.sun.tools.xjc.outline |
Provides the outline of the generated Java source code so that
additional processings (such as adding more annotations) can be
done on the generated code.
Code generation phase builds an outline little by little, while
each step is using the outline built by the prior steps.
|
com.sun.tools.xjc.reader | Front-end that reads schema(s) and produce BGM.
|
com.sun.tools.xjc.reader.dtd | |
com.sun.tools.xjc.reader.dtd.bindinfo | Object Model that represents DTD binding information.
|
com.sun.tools.xjc.reader.gbind |
Binary expressions are left-associative. IOW, ((A,B),C) instead of (A,(B,C))
|
com.sun.tools.xjc.reader.internalizer | internalization of external binding files and <jaxb:bindings> customizations.
|
com.sun.tools.xjc.reader.relaxng | |
com.sun.tools.xjc.reader.xmlschema | |
com.sun.tools.xjc.reader.xmlschema.bindinfo |
Object Model that represents customization declarations.
RelaxNGCC is used to parse
XML syntax into this representation, and the other parts of XJC will use
this object model.
|
com.sun.tools.xjc.reader.xmlschema.ct | |
com.sun.tools.xjc.reader.xmlschema.parser | |
com.sun.tools.xjc.runtime |
Code generated into the user's packages in certain compilation mode.
|
com.sun.tools.xjc.util | |
com.sun.tools.xjc.writer | |
com.sun.xml.dtdparser |
scan DTD stream and generates appropriate events.
|
com.sun.xml.xsom |
Interfaces that the client should use to access schema information.
|
com.sun.xml.xsom.impl |
Implementation of the com.sun.xml.xsom package.
|
com.sun.xml.xsom.impl.parser |
Parser that reads XML Schema documents and builds an XSSchemaSet object.
|
com.sun.xml.xsom.impl.parser.state | |
com.sun.xml.xsom.impl.scd | |
com.sun.xml.xsom.impl.util | |
com.sun.xml.xsom.parser |
Classes to parse XML Schema documents into objects of com.sun.xml.xsom package.
|
com.sun.xml.xsom.util | |
com.sun.xml.xsom.visitor |
Visitor pattern support for the com.sun.xml.xsom interfaces.
|
javax.xml.namespace | |
org.kohsuke.rngom.ast.builder | |
org.kohsuke.rngom.ast.om | |
org.kohsuke.rngom.ast.util | Typical implementations of the ast.builder/ast.om packages.
Those classes are solely intended to make the AST implementation easier.
|
org.kohsuke.rngom.binary |
Minimal binarized pattern object model (one example of ast.om implementation).
|
org.kohsuke.rngom.binary.visitor | |
org.kohsuke.rngom.digested |
Another RELAX NG AST implementation that optimizes away
inclusions and some other syntax sugars, while still retaining
all the annotations, location information, and etc.
|
org.kohsuke.rngom.dt | |
org.kohsuke.rngom.dt.builtin | RELAX NG built-in datatype implementation.
|
org.kohsuke.rngom.nc |
Default Name Class Object Model (one example of ast.om implementation).
|
org.kohsuke.rngom.parse | |
org.kohsuke.rngom.parse.compact | |
org.kohsuke.rngom.parse.host | implementation of the asm.builder package that uses two
other builds simultaneously.
|
org.kohsuke.rngom.parse.xml | |
org.kohsuke.rngom.util | |
org.kohsuke.rngom.xml.sax | |
org.kohsuke.rngom.xml.util | |
org.relaxng.datatype | |
org.relaxng.datatype.helpers | |