Removes all files from the output directory before running SchemaGenerator.

If true, Elements or Attributes in the generated XSD files will be annotated with any JavaDoc found for their respective properties. If false, no XML documentation annotations will be generated in post-processing any results from the JAXB SchemaGenerator.

Defines the encoding used by XJC (for generating Java Source files) and schemagen (for generating XSDs). The corresponding argument parameter for XJC and SchemaGen is: encoding.

The algorithm for finding the encoding to use is as follows (where the first non-null value found is used for encoding):

1. If the configuration property is explicitly given within the plugin's configuration, use that value.
2. If the Maven property project.build.sourceEncoding is defined, use its value.
3. Otherwise use the value from the system property file.encoding.

Corresponding SchemaGen parameter: episode.

Generate an episode file from this XSD generation, 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.)

If this parameter is true, the episode file generated is called META-INF/sun-jaxb.episode, and included in the artifact.

A renderer used to create XML annotation text from JavaDoc comments found within the source code. Unless another implementation is provided, the standard JavaDocRenderer used is DefaultJavaDocRenderer.

The directory where the generated XML Schema file(s) will be placed.

Parameter holding a List of Filters, used to match all files under the testSources directories which should not be considered SchemaGenerator testSource files. (The filters identify files to exclude, and hence this parameter is called testSchemaSourceExcludeFilters). If a file under any of the testSource directories matches at least one of the Filters supplied in the testSchemaSourceExcludeFilters, it is not considered an XJC test source file, and therefore excluded from processing.

If not explicitly provided, the Mojo uses the value within STANDARD_TEST_SOURCE_EXCLUDE_FILTERS. The algorithm for finding XJC sources is as follows:

1. Find all files given in the testSources List. Any Directories provided are searched for files recursively.
2. Exclude any found files matching any of the supplied testSchemaSourceExcludeFilters List.
3. The remaining Files are submitted for processing by the XJC tool.

Example: The following configuration would exclude any testSources whose names end with .txt or .foo:

    
       <configuration>
        ...
             <testSchemaSourceExcludeFilters>
                 <filter implementation="org.codehaus.mojo.jaxb2.shared.filters.pattern.PatternFileFilter">
                     <patterns>
                         <pattern>\.txt</pattern>
                         <pattern>\.foo</pattern>
                     </patterns>
                 </filter>
             </testSchemaSourceExcludeFilters>
        </configuration>
    

Note that inner workings of the Dependency Injection mechanism used by Maven Plugins (i.e. the DI from the Plexus container) requires that the full class name to the Filter implementation should be supplied for each filter, as is illustrated in the sample above. This is true also if you implement custom Filters.

The directory where the schemagen tool will output XSDs, episode files - and intermediary bytecode files. From this directory the XSDs and the episode file (but not the bytecode files) will be copied to the outputDirectory for further processing.

A List holding desired schema mappings, each of which binds a schema namespace URI to its desired prefix [optional] and the name of the resulting schema file [optional]. All given elements (uri, prefix, file) must be unique within the configuration; no two elements may have the same values.

The example schema configuration below maps two namespace uris to prefixes and generated file names. This implies that http://some/namespace will be represented by the prefix some within the generated XML Schema files; creating namespace definitions on the form xmlns:some="http://some/namespace", and corresponding uses on the form <xs:element minOccurs="0" ref="some:anOptionalElementInSomeNamespace"/>. Moreover, the file element defines that the http://some/namespace definitions will be written to the file some_schema.xsd, and that all import references will be on the form <xs:import namespace="http://some/namespace" schemaLocation="some_schema.xsd"/>

The example configuration below also performs identical operations for the namespace uri http://another/namespace with the prefix another and the file another_schema.xsd.

    
<transformSchemas>
  <transformSchema>
    <uri>http://some/namespace</uri>
    <toPrefix>some</toPrefix>
    <toFile>some_schema.xsd</toFile>
  <transformSchema>
    <uri>http://another/namespace</uri>
    <toPrefix>another</toPrefix>
    <toFile>another_schema.xsd</toFile>
  </transformSchema>
</transformSchemas>