diff --git a/maven-site/src/site/apt/guides/plugin/build-plugin.apt b/maven-site/src/site/apt/guides/plugin/build-plugin.apt deleted file mode 100644 index eedd0a6cdd..0000000000 --- a/maven-site/src/site/apt/guides/plugin/build-plugin.apt +++ /dev/null @@ -1,66 +0,0 @@ - ------ - Plugin Development Guide - Building a Plugin - ----- - Bob Allison - ------ - 12 October 2005 - ------ - - -Project Definition - - Once the mojos have been written for the plugin, it is time to - build the plugin. To do this properly, the project's descriptor - needs to have a number of settings set properly: - -*------------------+----------------------------------------------------------+ -|<<>> |This is the group ID for the plugin, and should match the | -| |common prefix to the packages used by the mojos | -*------------------+----------------------------------------------------------+ -|<<>> |This is the name of the plugin | -*------------------+----------------------------------------------------------+ -|<<>> |This is the version of the plugin | -*------------------+----------------------------------------------------------+ -|<<>> |This should be set to "<<>>" | -*------------------+----------------------------------------------------------+ -|<<>>|A dependency must be declared to the Maven Plugin Tools | -| |API to resolve "<<>>" and related classes | -*------------------+----------------------------------------------------------+ - - Listed below is a POM for a plugin which uses the simple sample mojo: - -+----+ - - 4.0.0 - sample.plugin - maven-hello-plugin - maven-plugin - 1.0-SNAPSHOT - Sample Parameter-less Maven Plugin - - - org.apache.maven - maven-plugin-tools-api - 2.0-beta-2 - - - -+----+ - -Build Goals - - There are a few goals which are defined with the Maven plugin - packaging as part of a standard build lifecycle: - -*-------------+----------------------------------------------------+ -|<<>>|Compiles the Java code for the plugin and builds the| -| |plugin descriptor | -*-------------+----------------------------------------------------+ -|<<>> |Runs the plugin's unit tests | -*-------------+----------------------------------------------------+ -|<<>>|Builds the plugin jar | -*-------------+----------------------------------------------------+ -|<<>>|Installs the plugin jar in the local repository | -*-------------+----------------------------------------------------+ -|<<>> |Deploys the plugin jar to the remote repository | -*-------------+----------------------------------------------------+ diff --git a/maven-site/src/site/apt/guides/plugin/first-mojo.apt b/maven-site/src/site/apt/guides/plugin/first-mojo.apt deleted file mode 100644 index e8a01b6a5a..0000000000 --- a/maven-site/src/site/apt/guides/plugin/first-mojo.apt +++ /dev/null @@ -1,66 +0,0 @@ - ------- - Plugin Development Guide - Your First Mojo - ------- - Bob Allison - ------- - 12 October 2005 - ------- - -Your First Mojo - - At its simplest, a Java mojo consists simply of a single class. There is - no requirement for multiple classes like EJBs, although a plugin which - contains a number of similar mojos is likely to use an abstract - superclass for the mojos to consolidate code common to all mojos. - - When processing the source tree to find mojos, the class - <<>> - looks for classes with a "<<>>" annotation on the class. Any class - with this annotation are included in the plugin configuration file. - -A Simple Mojo - - Listed below is a simple mojo class which has no parameters. This is - about as simple as a mojo can be. After the listing is a description - of the various parts of the source. - -+---+ -package sample.plugin; - -import org.apache.maven.plugin.AbstractMojo; -import org.apache.maven.plugin.MojoExecutionException; - -/** - * @goal sayhi - * @description Says "Hi" to the user - */ -public class GreetingMojo extends AbstractMojo { - public void execute() throws MojoExecutionException { - getLog().info("Hello, world."); - } -} -+---+ - - * The class <<>> provides most of the - infrastructure required to implement a mojo except for the - <<>> method. - - * The comment lines starting with "<<<@goal>>>" and "<<<@description>>>" - are examples of annotations. These two annotations are required, but - there are a number of annotations which can be used to control how and - when the mojo is executed. - - * The <<>> method can throw two exceptions: - - * <<>> if an unexpected - problem occurs. Throwing this exception causes a "BUILD ERROR" message - to be displayed. - - * <<>> if an expected - problem (such as a compilation failure) occurs. Throwing this exception - causes a "BUILD FAILURE" message to be displayed. - - * The <<>> method (defined in <<>>) returns a - log4j-like logger object which allows plugins to create messages at levels - of "debug", "info", "warn", and "error". This logger is the accepted means - to display information to the user. diff --git a/maven-site/src/site/apt/guides/plugin/first-plugin.apt b/maven-site/src/site/apt/guides/plugin/first-plugin.apt deleted file mode 100644 index 62d4df5b79..0000000000 --- a/maven-site/src/site/apt/guides/plugin/first-plugin.apt +++ /dev/null @@ -1,15 +0,0 @@ - ------- - Plugin Development Guide - Your First Plugin - ------- - Bob Allison - ------- - 12 October 2005 - ------- - -Your First Plugin - - This section of the document walks the reader through the process - of building a simple plugin which takes no parameters and simply - displays a message on the screen when run. It covers the basics of - setting up a project to create a plugin, the minimal contents of a - Java mojo, and the means to cause the mojo to be executed. diff --git a/maven-site/src/site/apt/guides/plugin/first-run.apt b/maven-site/src/site/apt/guides/plugin/first-run.apt deleted file mode 100644 index f941b8a4a8..0000000000 --- a/maven-site/src/site/apt/guides/plugin/first-run.apt +++ /dev/null @@ -1,73 +0,0 @@ - ------ - Plugin Development Guide - Executing Your First Mojo - ------ - Bob Allison - ------ - 12 October 2005 - ------ - - -Executing Your First Mojo - - The most direct means of executing your new plugin is to specify the - plugin goal directly on the command line. To do this, you need to - specify a fully-qualified goal in the form of: - -+----+ -groupID:artifactID:version:goal -+----+ - - For example, to run the simple mojo in the sample plugin, you would enter - "<<>>" on the - command line. - -Shortening the Command Line - - It is possible to shorten the amount of typing needed on the command - line. To do this, you need to install the plugin with the - <<>> option set to true; for example: - -+----+ -m2 -DupdateReleaseInfo=true install -+----+ - - You also need to add your plugin's group ID to the list of group IDs - searched by default. To do this, you need to add the following to - your <<>> file: - -+----+ - - sample.plugin - -+----+ - - At this point, you can run the mojo with "<<>>". - - -Attaching the Mojo to the Build Lifecycle - - You can also configure your plugin to attach specific goals to a particular - phase of the build lifecycle. Here is an example: - -+-----+ - - - - sample.plugin - maven-hello-plugin - - - compile - - sayhi - - - - - - -+-----+ - - This causes the simple mojo to be executed whenever Java code is compiled. - For more information on binding a mojo to phases in the lifecycle, please - refer to the {{{/maven2/lifecycle.html}Build Lifecycle}} document. \ No newline at end of file diff --git a/maven-site/src/site/apt/guides/plugin/guide-java-plugin-development.apt b/maven-site/src/site/apt/guides/plugin/guide-java-plugin-development.apt new file mode 100644 index 0000000000..39fba27db3 --- /dev/null +++ b/maven-site/src/site/apt/guides/plugin/guide-java-plugin-development.apt @@ -0,0 +1,395 @@ + ------ + Guide to Developing Java Plugins + ------ + Bob Allison + ------ + 12 October 2005 + ------ + +~~ Copyright 2001-2005 The Apache Software Foundation. +~~ +~~ Licensed under the Apache License, Version 2.0 (the "License"); +~~ you may not use this file except in compliance with the License. +~~ You may obtain a copy of the License at +~~ +~~ http://www.apache.org/licenses/LICENSE-2.0 +~~ +~~ Unless required by applicable law or agreed to in writing, software +~~ distributed under the License is distributed on an "AS IS" BASIS, +~~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +~~ See the License for the specific language governing permissions and +~~ limitations under the License. + +Introduction + + This guide is intended to assist users in developing Java plugins for + Maven 2.0. + +* Your First Plugin + + In this section we will build a simple plugin which takes no parameters + and simply displays a message on the screen when run. Along the way, we + will cover the basics of setting up a project to create a plugin, the + minimal contents of a Java mojo, and a couple ways to execute the mojo. + +** Your First Mojo + + At its simplest, a Java mojo consists simply of a single class. There is + no requirement for multiple classes like EJBs, although a plugin which + contains a number of similar mojos is likely to use an abstract + superclass for the mojos to consolidate code common to all mojos. + + When processing the source tree to find mojos, the class + <<>> + looks for classes with a "<<>>" annotation on the class. Any class + with this annotation are included in the plugin configuration file. + +*** A Simple Mojo + + Listed below is a simple mojo class which has no parameters. This is + about as simple as a mojo can be. After the listing is a description + of the various parts of the source. + ++---+ +package sample.plugin; + +import org.apache.maven.plugin.AbstractMojo; +import org.apache.maven.plugin.MojoExecutionException; + +/** + * @goal sayhi + * @description Says "Hi" to the user + */ +public class GreetingMojo extends AbstractMojo { + public void execute() throws MojoExecutionException { + getLog().info("Hello, world."); + } +} ++---+ + + * The class <<>> provides most of the + infrastructure required to implement a mojo except for the + <<>> method. + + * The comment lines starting with "<<<@goal>>>" and "<<<@description>>>" + are examples of annotations. These two annotations are required, but + there are a number of annotations which can be used to control how and + when the mojo is executed. + + * The <<>> method can throw two exceptions: + + * <<>> if an unexpected + problem occurs. Throwing this exception causes a "BUILD ERROR" message + to be displayed. + + * <<>> if an expected + problem (such as a compilation failure) occurs. Throwing this exception + causes a "BUILD FAILURE" message to be displayed. + + * The <<>> method (defined in <<>>) returns a + log4j-like logger object which allows plugins to create messages at levels + of "debug", "info", "warn", and "error". This logger is the accepted means + to display information to the user. + +** Project Definition + + Once the mojos have been written for the plugin, it is time to + build the plugin. To do this properly, the project's descriptor + needs to have a number of settings set properly: + +*------------------+----------------------------------------------------------+ +|<<>> |This is the group ID for the plugin, and should match the | +| |common prefix to the packages used by the mojos | +*------------------+----------------------------------------------------------+ +|<<>> |This is the name of the plugin | +*------------------+----------------------------------------------------------+ +|<<>> |This is the version of the plugin | +*------------------+----------------------------------------------------------+ +|<<>> |This should be set to "<<>>" | +*------------------+----------------------------------------------------------+ +|<<>>|A dependency must be declared to the Maven Plugin Tools | +| |API to resolve "<<>>" and related classes | +*------------------+----------------------------------------------------------+ + + Listed below is a POM for a plugin which uses the simple sample mojo: + ++----+ + + 4.0.0 + sample.plugin + maven-hello-plugin + maven-plugin + 1.0-SNAPSHOT + Sample Parameter-less Maven Plugin + + + org.apache.maven + maven-plugin-tools-api + 2.0 + + + ++----+ + +** Build Goals + + There are a few goals which are defined with the Maven plugin + packaging as part of a standard build lifecycle: + +*-------------+----------------------------------------------------+ +|<<>>|Compiles the Java code for the plugin and builds the| +| |plugin descriptor | +*-------------+----------------------------------------------------+ +|<<>> |Runs the plugin's unit tests | +*-------------+----------------------------------------------------+ +|<<>>|Builds the plugin jar | +*-------------+----------------------------------------------------+ +|<<>>|Installs the plugin jar in the local repository | +*-------------+----------------------------------------------------+ +|<<>> |Deploys the plugin jar to the remote repository | +*-------------+----------------------------------------------------+ + +** Executing Your First Mojo + + The most direct means of executing your new plugin is to specify the + plugin goal directly on the command line. To do this, you need to + specify a fully-qualified goal in the form of: + ++----+ +groupID:artifactID:version:goal ++----+ + + For example, to run the simple mojo in the sample plugin, you would enter + "<<>>" on the + command line. + +*** Shortening the Command Line + + It is possible to shorten the amount of typing needed on the command + line. To do this, you need to install the plugin with the + <<>> option set to true; for example: + ++----+ +m2 -DupdateReleaseInfo=true install ++----+ + + You also need to add your plugin's group ID to the list of group IDs + searched by default. To do this, you need to add the following to + your <<>> file: + ++----+ + + sample.plugin + ++----+ + + At this point, you can run the mojo with "<<>>". + + +*** Attaching the Mojo to the Build Lifecycle + + You can also configure your plugin to attach specific goals to a particular + phase of the build lifecycle. Here is an example: + ++-----+ + + + + sample.plugin + maven-hello-plugin + + + compile + + sayhi + + + + + + ++-----+ + + This causes the simple mojo to be executed whenever Java code is compiled. + For more information on binding a mojo to phases in the lifecycle, please + refer to the {{{/maven2/lifecycle.html}Build Lifecycle}} document. + + +* Parameters + + It is unlikely that a mojo will be very useful without parameters. + Parameters provide a few very important functions: + + * It provides hooks to allow the user to adjust the operation of the + plugin to suit their needs. + + * It provides a means to easily extract the value of elements from + the POM without the need to navigate the objects. + +** Defining Parameters Within a Mojo + + Defining a parameter is as simple as creating an instance variable + in the mojo and adding the proper annotations. Listed below is an + example of a parameter for the simple mojo: + ++-----+ + /** + * The greeting to display. + * @parameter expression="Hello" + */ + private String greeting; ++-----+ + + The portion before the annotations is the description of the + parameter. The "<<>>" annotation identifies + the variable as a mojo parameter. The "<<>>" + parameter defines the default value for the variable. This value can + include expressions which reference the project, such as + "<<<${project.version}>>>" (more can be found in the + "Parameter Expressions" document). The name of the variable is used + as the name of the parameter. + +** Configuring Parameters in a Project + + Configuring the parameter values for a plugin is done in a Maven 2 + project within the <<>> file as part of defining the + plugin in the project. An example of configuring a plugin: + ++-----+ + + sample.plugin + maven-hello-plugin + + Welcome + + ++-----+ + + In the configuration section, the element name + ("<<>>") is the parameter name and the contents of + the element ("<<>>") is the value to be assigned to + the parameter. More details can be found in the + {{{../mini/guide-configuring-plugins.html}Guide to Configuring Plugins}}. + +** Parameter Types With One Value + + Listed below are the various types of simple variables which can be used as + parameters in your mojos, along with any rules on how the values in the + POM are interpreted. + +*** Boolean + + This includes variables typed <<>> and <<>>. When reading + the configuration, the text "<<>>" causes the parameter to be set to + true and all other text causes the parameter to be set to false. + +*** Fixed-Point Numbers + + This includes variables typed <<>>, <<>>, <<>>, + <<>>, <<>>, <<>>, <<>>, and <<>>. When + reading the configuration, the text in the XML file is converted to an + integer value using either <<>> or the <<>> + method of the appropriate class. This means that the strings must be valid + decimal integer values, consisting only of the digits 0 to 9 with an optional + <<<->>> in front for a negative value. + +*** Floating-Point Numbers + + This includes variables typed <<>>, <<>>, <<>>, and + <<>>. When reading the configuration, the text in the XML file is + converted to binary form using the <<>> method for the appropriate + class. This means that the strings can take on any format specified in + section 3.10.2 of the Java Language Specification. Some samples of valid + values are <<<1.0>>> and <<<6.02E+23>>>. + +*** Dates + + This includes variables typed <<>>. When reading the configuration, + the text in the XML file is converted using one of the following date + formats: "<<>>" (a sample date is "2005-10-06 + 2:22:55.1 PM") or "<<>>" (a sample date is "2005-10-06 + 2:22:55PM"). Note that parsing is done using <<>> which + allows some leniency in formatting. If the method can parse a date and time + out of what is specified it will do so even if it doesn't exactly match the + patterns above. + +*** Files and Directories + + This includes variables typed <<>>. When reading the configuration, + the text in the XML file is used as the path to the desired file or + directory. If the path is relative (does not start with <<>> or a drive + letter like <<>>), the path is relative to the directory containing + the POM. + +*** URLs + + This includes variables typed <<>>. When reading the configuration, the + text in the XML file is used as the URL. The format must follow the RFC 2396 + guidelines, and looks like any web browser URL + (<<>>). No restrictions are placed on the + content of any of the parts of the URL while converting the URL. + +*** Plain Text + + This includes variables typed <<>>, <<>>, <<>>, + and <<>>. When reading the configuration, the text in the XML file is + used as the value to be assigned to the parameter. For <<>> and + <<>> parameters, only the first character of the text is used. + +** Parameter Types With Multiple Values + + Listed below are the various types of composite objects which can be used as + parameters in your mojos, along with any rules on how the values in the + POM are interpreted. In general, the class of the object created to hold the + parameter value (as well as the class for each element within the parameter + value) is determined as follows (the first step which yields a valid class + is used): + + [[1]] If the XML contains an <<>> hint, that is used + + [[2]] If the XML tag contains a <<<.>>>, try that as a class name + + [[3]] Try the XML tag as a class in the same package as the object being + configured + + [[4]] For arrays, use the class of the array (for example, use <<>> + for a <<>> parameter); for collections and maps, use the + class specified in the mojo configuration for the collection or map; + use <<>> for entries in a collection and values in a map + + Once the type for the element is defined, the text in the XML file is + converted to the appropriate type of object + +*** Arrays + + Array type parameters are configured by specifying the parameter multiple + times (for example, "<<< value1 value2 >>>"). + +*** Collections + + This category covers any class which implements <<>> + such as <<>> or <<>>. These parameters are configured by + specifying the parameter multiple times just like an array. + +*** Maps + + This category covers any class which implements <<>> + such as <<>> but does <> implement <<>>. + These parameters are configured by including XML tags in the form + <<< value >>> in the parameter configuration. + +*** Properties + + This category covers any map which implements <<>>. + These parameters are configured by including XML tags in the form + <<< value >>> in the parameter configuration. + +*** Other Object Classes + + This category covers any class which does not implement <<>>, + <<>>, or <<>>. + +* Resources + + [[1]] {{{developers/mojo-api-specification.html}Mojo API specification}} + diff --git a/maven-site/src/site/apt/guides/plugin/guide-plugin-development.apt b/maven-site/src/site/apt/guides/plugin/guide-plugin-development.apt deleted file mode 100644 index b1125c0431..0000000000 --- a/maven-site/src/site/apt/guides/plugin/guide-plugin-development.apt +++ /dev/null @@ -1,57 +0,0 @@ - ------ -Plugin Development Guide - ------ -John Casey - ------ -24 June 2005 - ------ - -~~ Copyright 2001-2004 The Apache Software Foundation. -~~ -~~ Licensed under the Apache License, Version 2.0 (the "License"); -~~ you may not use this file except in compliance with the License. -~~ You may obtain a copy of the License at -~~ -~~ http://www.apache.org/licenses/LICENSE-2.0 -~~ -~~ Unless required by applicable law or agreed to in writing, software -~~ distributed under the License is distributed on an "AS IS" BASIS, -~~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -~~ See the License for the specific language governing permissions and -~~ limitations under the License. - -Developing Maven 2.0 Plugins - -* Introduction - -* Your First Plugin () - -** Write the Mojo - -** Annotate the Mojo - -** Build the Plugin () - - -* Plugins in the Build - -** I Want My preReqs! - -** Decorating Existing Builds () - -** Getting Information into the Plugin () - - -* Plugins in the Wild - -** Why Might a Plugin Be Maven-Centric? - -** Curing Dependence on Maven - -** Injecting Configuration into a Plugin - - -* Resources - - [[1]] {{{developers/mojo-api-specification.html}Mojo API specification}} - diff --git a/maven-site/src/site/apt/guides/plugin/index.apt b/maven-site/src/site/apt/guides/plugin/index.apt deleted file mode 100644 index 8abbfd6212..0000000000 --- a/maven-site/src/site/apt/guides/plugin/index.apt +++ /dev/null @@ -1,17 +0,0 @@ - ------ - Plugin Development Guide - Introduction - ------ - Bob Allison - ------ - 12 October 2005 - ----- - -Introduction - - This web site contains documentation to assist users in developing - their own plugins. \xAB\xBB - - \xAB\xBB diff --git a/maven-site/src/site/apt/guides/plugin/params.apt b/maven-site/src/site/apt/guides/plugin/params.apt deleted file mode 100644 index 6b5caf93f6..0000000000 --- a/maven-site/src/site/apt/guides/plugin/params.apt +++ /dev/null @@ -1,184 +0,0 @@ - ----- - Plugin Development Guide - Adding Parameters - ----- - -What Are Parameters - - It is unlikely that a mojo will be very useful without parameters. - Parameters provide a few very important functions: - - * It provides hooks to allow the user to adjust the operation of the - plugin to suit their needs. - - * It provides a means to easily extract the value of elements from - the POM without the need to navigate the objects. - -Defining Parameters Within a Mojo - - Defining a parameter is as simple as creating an instance variable - in the mojo and adding the proper annotations. Listed below is an - example of a parameter for the simple mojo: - -+-----+ - /** - * The greeting to display. - * @parameter expression="Hello" - */ - private String greeting; -+-----+ - - The portion before the annotations is the description of the - parameter. The "<<>>" annotation identifies - the variable as a mojo parameter. The "<<>>" - parameter defines the default value for the variable. This value can - include expressions which reference the project, such as - "<<<${project.version}>>>" (more can be found in the - "Parameter Expressions" document). The name of the variable is used - as the name of the parameter. - -Configuring Parameters in a Project - - Configuring the parameter values for a plugin is done in a Maven 2 - project within the <<>> file as part of defining the - plugin in the project. An example of configuring a plugin: - -+-----+ - - sample.plugin - maven-hello-plugin - - Welcome - - -+-----+ - - In the configuration section, the element name - ("<<>>") is the parameter name and the contents of - the element ("<<>>") is the value to be assigned to - the parameter. More details can be found in the Getting Started - Guide section on - {{{/maven2/getting-started.html#configuring_plugins}configuring plugins}}. - -Parameter Types With One Value - - Listed below are the various types of simple variables which can be used as - parameters in your mojos, along with any rules on how the values in the - POM are interpreted. - -* Boolean - - This includes variables typed <<>> and <<>>. When reading - the configuration, the text "<<>>" causes the parameter to be set to - true and all other text causes the parameter to be set to false. - -* Fixed-Point Numbers - - This includes variables typed <<>>, <<>>, <<>>, - <<>>, <<>>, <<>>, <<>>, and <<>>. When - reading the configuration, the text in the XML file is converted to an - integer value using either <<>> or the <<>> - method of the appropriate class. This means that the strings must be valid - decimal integer values, consisting only of the digits 0 to 9 with an optional - <<<->>> in front for a negative value. - -* Floating-Point Numbers - - This includes variables typed <<>>, <<>>, <<>>, and - <<>>. When reading the configuration, the text in the XML file is - converted to binary form using the <<>> method for the appropriate - class. This means that the strings can take on any format specified in - section 3.10.2 of the Java Language Specification. Some samples of valid - values are <<<1.0>>> and <<<6.02E+23>>>. - -* Dates - - This includes variables typed <<>>. When reading the configuration, - the text in the XML file is converted using one of the following date - formats: "<<>>" (a sample date is "2005-10-06 - 2:22:55.1 PM") or "<<>>" (a sample date is "2005-10-06 - 2:22:55PM"). Note that parsing is done using <<>> which - allows some leniency in formatting. If the method can parse a date and time - out of what is specified it will do so even if it doesn't exactly match the - patterns above. - -* Files and Directories - - This includes variables typed <<>>. When reading the configuration, - the text in the XML file is used as the path to the desired file or - directory. If the path is relative (does not start with <<>> or a drive - letter like <<>>), the path is relative to the directory containing - the POM. - -* URLs - - This includes variables typed <<>>. When reading the configuration, the - text in the XML file is used as the URL. The format must follow the RFC 2396 - guidelines, and looks like any web browser URL - (<<>>). No restrictions are placed on the - content of any of the parts of the URL while converting the URL. - -* Plain Text - - This includes variables typed <<>>, <<>>, <<>>, - and <<>>. When reading the configuration, the text in the XML file is - used as the value to be assigned to the parameter. For <<>> and - <<>> parameters, only the first character of the text is used. - -Parameter Types With Multiple Values - - Listed below are the various types of composite objects which can be used as - parameters in your mojos, along with any rules on how the values in the - POM are interpreted. In general, the class of the object created to hold the - parameter value (as well as the class for each element within the parameter - value) is determined as follows (the first step which yields a valid class - is used): - - [[1]] If the XML contains an <<>> hint, that is used - - [[2]] If the XML tag contains a <<<.>>>, try that as a class name - - [[3]] Try the XML tag as a class in the same package as the object being - configured - - [[4]] For arrays, use the class of the array (for example, use <<>> - for a <<>> parameter); for collections and maps, use the - class specified in the mojo configuration for the collection or map; - use <<>> for entries in a collection and values in a map - - Once the type for the element is defined, the text in the XML file is - converted to the appropriate type of object - -* Arrays - - Array type parameters are configured by specifying the parameter multiple - times (for example, "<<< value1 value2 >>>"). - -* Collections - - This category covers any class which implements <<>> - such as <<>> or <<>>. These parameters are configured by - specifying the parameter multiple times just like an array. - -* Maps - - This category covers any class which implements <<>> - such as <<>> but does <> implement <<>>. - These parameters are configured by including XML tags in the form - <<< value >>> in the parameter configuration. - -* Properties - - This category covers any map which implements <<>>. - These parameters are configured by including XML tags in the form - <<< value >>> in the parameter configuration. \xAB.>\xBB - -* Other Object Classes - - This category covers any class which does not implement <<>>, - <<>>, or <<>>. - These parameters are configured by \xAB\xBB \ No newline at end of file