You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-commits@maven.apache.org by sv...@apache.org on 2019/06/09 13:59:37 UTC
svn commit: r1860906 [12/22] - in /maven/website/content: ./
apache-resource-bundles/ archives/maven-2.x/ background/ developers/
developers/conventions/ developers/release/ developers/website/ docs/
docs/2.0.1/ docs/2.0.10/ docs/2.0.11/ docs/2.0.2/ do...
Modified: maven/website/content/guides/mini/guide-building-for-different-environments.html
==============================================================================
--- maven/website/content/guides/mini/guide-building-for-different-environments.html (original)
+++ maven/website/content/guides/mini/guide-building-for-different-environments.html Sun Jun 9 13:59:34 2019
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from content/apt/guides/mini/guide-building-for-different-environments.apt at 2019-06-09
+ | Generated by Apache Maven Doxia Site Renderer 1.9 from content/apt/guides/mini/guide-building-for-different-environments.apt at 2019-06-09
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
@@ -160,7 +160,7 @@
</div>
</div>
<div id="bodyColumn" class="span10" >
-<div class="section">
+<section>
<h2><a name="Building_For_Different_Environments_with_Maven_2"></a>Building For Different Environments with Maven 2</h2>
<p>Building the same artifact for different environments has always been an annoyance. You have multiple environments, for instance test and production servers or, maybe a set of servers that run the same application with different configurations. In this guide I'll explain how you can use profiles to build and package artifacts configured for specific environments. See <a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a> for a more in-depth explanation of the profile concept.</p>
<p>Note:</p>
@@ -176,11 +176,11 @@ src/
resources/
test/
java/</pre></div></li></ul>
-<p>Under <tt>src/main/resources</tt> there are three files:</p>
+<p>Under <code>src/main/resources</code> there are three files:</p>
<ul>
-<li><tt>environment.properties</tt> - This is the default configuration and will be packaged in the artifact by default.</li>
-<li><tt>environment.test.properties</tt> - This is the variant for the test environment.</li>
-<li><tt>environment.prod.properties</tt> - This is basically the same as the test variant and will be used in the production environment.
+<li><code>environment.properties</code> - This is the default configuration and will be packaged in the artifact by default.</li>
+<li><code>environment.test.properties</code> - This is the variant for the test environment.</li>
+<li><code>environment.prod.properties</code> - This is basically the same as the test variant and will be used in the production environment.
<p>In the project descriptor, you need to configure the different profiles. Only the test profile is showed here.</p>
<div>
<pre> <profiles>
@@ -235,22 +235,20 @@ src/
</profiles></pre></div>
<p>Three things are configured in this snippet:</p>
<ol style="list-style-type: decimal">
-<li>It configures the antrun plugin to execute the run goal in the test phase where it will copy the <tt>environment.test.properties</tt> file to <tt>environment.properties</tt>.</li>
+<li>It configures the antrun plugin to execute the run goal in the test phase where it will copy the <code>environment.test.properties</code> file to <code>environment.properties</code>.</li>
<li>It will configure the test plugin to skip all tests when building the test and production artifacts. This is useful as you probably don't want to run tests against the production system</li>
<li>It configures the JAR plugin to create an "attached" JAR with the "test" classifier.
-<p>To activate this profile execute <tt>mvn -Ptest install</tt> and Maven will execute the steps in the profile in addition to the normal steps. From this build you will get two artifacts, "foo-1.0.jar" and "foo-1.0-test.jar". These two jars will identical. </p></li></ol></li></ul></div>
-<div class="section">
+<p>To activate this profile execute <code>mvn -Ptest install</code> and Maven will execute the steps in the profile in addition to the normal steps. From this build you will get two artifacts, "foo-1.0.jar" and "foo-1.0-test.jar". These two jars will identical. </p></li></ol></li></ul></section><section>
<h2><a name="Caveats"></a>Caveats</h2>
<ul>
<li>Currently Maven 2 doesn't allow a project build to only produce attached artifacts. (i.e. it has to produce a "main" artifact as well) This results in two equal JARs being packaged and installed. The JAR plugin probably should also get improved support for this use case to that two different output directories will be used as the basis for building the JAR.</li>
<li>The usage of the delete task might seem a bit odd but is required to make sure that the copy task actually will copy the file. The copy task will look at the timestamps of the source and destination files, only when copying the files it won't know that the actually source file might be different than the last time it was executed.</li>
<li>After the build the test configuration will be in target/classes and won't be overridden because the resources plugin uses the same timestamp checking, so you should always do a clean after executing Maven with a profile.</li>
-<li>For the reasons given above it's imperative that you only build an artifact for a single environment in a single execution at a time and that you execute "mvn clean" whenever you change the profile switches. If not, you might get artifacts with a mixed set of configuration files.</li></ul></div>
-<div class="section">
+<li>For the reasons given above it's imperative that you only build an artifact for a single environment in a single execution at a time and that you execute "mvn clean" whenever you change the profile switches. If not, you might get artifacts with a mixed set of configuration files.</li></ul></section><section>
<h2><a name="Resources"></a>Resources</h2>
<ol style="list-style-type: decimal">
<li><a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a></li>
-<li><a href="../introduction/introduction-to-the-standard-directory-layout.html">Standard Directory Layout</a></li></ol></div>
+<li><a href="../introduction/introduction-to-the-standard-directory-layout.html">Standard Directory Layout</a></li></ol></section>
</div>
</div>
</div>
Modified: maven/website/content/guides/mini/guide-building-jdk14-on-jdk15.html
==============================================================================
--- maven/website/content/guides/mini/guide-building-jdk14-on-jdk15.html (original)
+++ maven/website/content/guides/mini/guide-building-jdk14-on-jdk15.html Sun Jun 9 13:59:34 2019
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from content/apt/guides/mini/guide-building-jdk14-on-jdk15.apt at 2019-06-09
+ | Generated by Apache Maven Doxia Site Renderer 1.9 from content/apt/guides/mini/guide-building-jdk14-on-jdk15.apt at 2019-06-09
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
@@ -160,23 +160,20 @@
</div>
</div>
<div id="bodyColumn" class="span10" >
-<div class="section">
+<section>
<h2><a name="Guide_to_Building_JDK_1.4_Projects_Using_JDK_1.5"></a>Guide to Building JDK 1.4 Projects Using JDK 1.5</h2>
<p>Since Maven 2.2.0 requires Java 1.5 to execute, users who still require their projects to run on Java 1.4 or older will need to make some adjustments.</p>
-<p>Ideally, you could solve this problem by using JDK 1.4 to compile and test your project, by providing the appropriate <a href="./guide-using-toolchains.html">toolchains</a> configuration. However, the current release of the <a href="/plugins/maven-compiler-plugin">compiler plugin</a> (2.0.2) isn't toolchains-capable yet, so constructing a bullet-proof build using Maven 2.2.0 to target a Java platform older than 1.5 requires some more exotic configuration.</p>
-<div class="section">
-<h3><a name="First_Step:_Source_and_Target_Configurations"></a>First Step: <tt>Source</tt> and <tt>Target</tt> Configurations</h3>
-<p>The first step to supporting JDKs older than 1.5 in your build is already done for you: setting the <tt>source</tt> and <tt>target</tt> API versions in the configuration for the compiler plugin. Since JDK 1.5+ can still generate class files that are compliant with older JDKs, using this default compiler-plugin setting will render project artifacts that are technically compatible with JVMs older than 1.5.</p>
-<p>This is great, until someone sneaks a <tt>String.contains( "foo" )</tt> into the codebase. If that happens, your project will still build successfully, and generate 1.4-compatible binaries. But try to execute your code in a 1.4 JVM, and you'll understand why the compiler configuration alone isn't enough. To construct a build process targeting JVM 1.4 when the build tool requires JVM 1.5+, while still ensuring the result of that build is safe to run on the 1.4 JVM, we need to use a tool that can verify the compatibility of our project code against a given Java API specification version.</p></div>
-<div class="section">
+<p>Ideally, you could solve this problem by using JDK 1.4 to compile and test your project, by providing the appropriate <a href="./guide-using-toolchains.html">toolchains</a> configuration. However, the current release of the <a href="/plugins/maven-compiler-plugin">compiler plugin</a> (2.0.2) isn't toolchains-capable yet, so constructing a bullet-proof build using Maven 2.2.0 to target a Java platform older than 1.5 requires some more exotic configuration.</p><section>
+<h3><a name="First_Step:_Source_and_Target_Configurations"></a>First Step: <code>Source</code> and <code>Target</code> Configurations</h3>
+<p>The first step to supporting JDKs older than 1.5 in your build is already done for you: setting the <code>source</code> and <code>target</code> API versions in the configuration for the compiler plugin. Since JDK 1.5+ can still generate class files that are compliant with older JDKs, using this default compiler-plugin setting will render project artifacts that are technically compatible with JVMs older than 1.5.</p>
+<p>This is great, until someone sneaks a <code>String.contains( "foo" )</code> into the codebase. If that happens, your project will still build successfully, and generate 1.4-compatible binaries. But try to execute your code in a 1.4 JVM, and you'll understand why the compiler configuration alone isn't enough. To construct a build process targeting JVM 1.4 when the build tool requires JVM 1.5+, while still ensuring the result of that build is safe to run on the 1.4 JVM, we need to use a tool that can verify the compatibility of our project code against a given Java API specification version.</p></section><section>
<h3><a name="Enter_the_Animal_Sniffer"></a>Enter the Animal Sniffer</h3>
<p>Fortunately, there is a project at dev.java.net called <a class="externalLink" href="https://animal-sniffer.dev.java.net/signature-checker.html">Animal Sniffer</a> that does exactly what we need. This project can verify the compatibility of a codebase against a whole range of Java APIs. Even better, it provides a Maven 2.x plugin to give users an easy way to integrate these checks into their build. To verify that your codebase complies with JDK 1.4 API, you simply tell the animal sniffer plugin to use:</p>
<div class="source"><pre class="prettyprint linenums"><signature>
<groupId>org.jvnet.animal-sniffer</groupId>
<artifactId>java1.4</artifactId>
<version>1.0</version>
-</signature></pre></div></div>
-<div class="section">
+</signature></pre></div></section><section>
<h3><a name="Sample_Configuration"></a>Sample Configuration</h3>
<p>Putting it all together, the following example shows how you can be certain your project will run on the 1.4 JVM:</p>
<div class="source"><pre class="prettyprint linenums"><build>
@@ -216,7 +213,7 @@
</executions>
</plugin>
</plugins>
-</build></pre></div></div></div>
+</build></pre></div></section></section>
</div>
</div>
</div>
Modified: maven/website/content/guides/mini/guide-configuring-maven.html
==============================================================================
--- maven/website/content/guides/mini/guide-configuring-maven.html (original)
+++ maven/website/content/guides/mini/guide-configuring-maven.html Sun Jun 9 13:59:34 2019
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from content/apt/guides/mini/guide-configuring-maven.apt at 2019-06-09
+ | Generated by Apache Maven Doxia Site Renderer 1.9 from content/apt/guides/mini/guide-configuring-maven.apt at 2019-06-09
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
@@ -160,43 +160,39 @@
</div>
</div>
<div id="bodyColumn" class="span10" >
-<div class="section">
+<section>
<h2><a name="Configuring_Maven"></a>Configuring Maven</h2>
<p>Maven configuration occurs at 3 levels:</p>
<ul>
-<li><i>Project</i> - most static configuration occurs in <tt>pom.xml</tt></li>
+<li><i>Project</i> - most static configuration occurs in <code>pom.xml</code></li>
<li><i>Installation</i> - this is configuration added once for a Maven installation</li>
<li><i>User</i> - this is configuration specific to a particular user</li></ul>
<p>The separation is quite clear - the project defines information that applies to the project, no matter who is building it, while the others both define settings for the current environment.</p>
-<p><b>Note:</b> the installation and user configuration cannot be used to add shared project information - for example, setting <tt><organization></tt> or <tt><distributionManagement></tt> company-wide.</p>
-<p>For this, you should have your projects inherit from a company-wide parent <tt>pom.xml</tt>.</p>
-<p>You can specify your user configuration in <tt>${user.home}/.m2/settings.xml</tt>. A <a href="../../maven-settings/settings.html">full reference</a> to the configuration file is available. This section will show how to make some common configurations. Note that the file is not required - defaults will be used if it is not found.</p>
-<div class="section">
+<p><b>Note:</b> the installation and user configuration cannot be used to add shared project information - for example, setting <code><organization></code> or <code><distributionManagement></code> company-wide.</p>
+<p>For this, you should have your projects inherit from a company-wide parent <code>pom.xml</code>.</p>
+<p>You can specify your user configuration in <code>${user.home}/.m2/settings.xml</code>. A <a href="../../maven-settings/settings.html">full reference</a> to the configuration file is available. This section will show how to make some common configurations. Note that the file is not required - defaults will be used if it is not found.</p><section>
<h3><a name="Configuring_your_Local_Repository"></a>Configuring your Local Repository</h3>
-<p>The location of your local repository can be changed in your user configuration. The default value is <tt>${user.home}/.m2/repository/</tt>.</p>
+<p>The location of your local repository can be changed in your user configuration. The default value is <code>${user.home}/.m2/repository/</code>.</p>
<div>
<pre><settings>
...
<localRepository>/path/to/local/repo/</localRepository>
...
</settings></pre></div>
-<p><b>Note:</b> The local repository must be an absolute path.</p></div>
-<div class="section">
+<p><b>Note:</b> The local repository must be an absolute path.</p></section><section>
<h3><a name="Configuring_a_Proxy"></a>Configuring a Proxy</h3>
<p>Proxy configuration can also be specified in the settings file.</p>
-<p>For more information, see the <a href="./guide-proxies.html"> Guide to using a Proxy</a>.</p></div>
-<div class="section">
+<p>For more information, see the <a href="./guide-proxies.html"> Guide to using a Proxy</a>.</p></section><section>
<h3><a name="Configuring_Parallel_Artifact_Resolution"></a>Configuring Parallel Artifact Resolution</h3>
-<p>By default, Maven 2.1.0+ will download up to 5 artifacts (from different groups) at once. To change the size of the thread pool, start Maven using <tt>-Dmaven.artifact.threads</tt>. For example, to only download single artifacts at a time:</p>
+<p>By default, Maven 2.1.0+ will download up to 5 artifacts (from different groups) at once. To change the size of the thread pool, start Maven using <code>-Dmaven.artifact.threads</code>. For example, to only download single artifacts at a time:</p>
<div>
<pre>mvn -Dmaven.artifact.threads=1 verify</pre></div>
-<p>You may wish to set this option permanently, in which case you can use the <tt>MAVEN_OPTS</tt> environment variable. For example:</p>
+<p>You may wish to set this option permanently, in which case you can use the <code>MAVEN_OPTS</code> environment variable. For example:</p>
<div>
-<pre>export MAVEN_OPTS=-Dmaven.artifact.threads=3</pre></div></div>
-<div class="section">
+<pre>export MAVEN_OPTS=-Dmaven.artifact.threads=3</pre></div></section><section>
<h3><a name="Security_and_Deployment_Settings"></a>Security and Deployment Settings</h3>
-<p>Repositories to deploy to are defined in a project in the <tt><distributionManagement></tt> section. However, you cannot put your username, password, or other security settings in that project. For that reason, you should add a server definition to your own settings with an <tt>id</tt> that matches that of the deployment repository in the project.</p>
-<p>In addition, some repositories may require authorization to download from, so the corresponding settings can be specified in a <tt>server</tt> element in the same way.</p>
+<p>Repositories to deploy to are defined in a project in the <code><distributionManagement></code> section. However, you cannot put your username, password, or other security settings in that project. For that reason, you should add a server definition to your own settings with an <code>id</code> that matches that of the deployment repository in the project.</p>
+<p>In addition, some repositories may require authorization to download from, so the corresponding settings can be specified in a <code>server</code> element in the same way.</p>
<p>Which settings are required will depend on the type of repository you are deploying to. As of the first release, only SCP deployments and file deployments are supported by default, so only the following SCP configuration is needed:</p>
<div>
<pre><settings>
@@ -215,17 +211,13 @@
</servers>
...
</settings></pre></div>
-<p>To encrypt passwords in these sections, refer to <a href="./guide-encryption.html"> Encryption Settings</a>.</p></div>
-<div class="section">
+<p>To encrypt passwords in these sections, refer to <a href="./guide-encryption.html"> Encryption Settings</a>.</p></section><section>
<h3><a name="Using_Mirrors_for_Repositories"></a>Using Mirrors for Repositories</h3>
-<p>Repositories can be declared inside a project, which means that if you have your own custom repositories, those sharing your project easily get the right settings out of the box. However, you may want to use an alternative mirror for a particular repository without changing the project files. Refer to <a href="./guide-mirror-settings.html"> Guide to Mirror Settings</a> for more details.</p></div>
-<div class="section">
+<p>Repositories can be declared inside a project, which means that if you have your own custom repositories, those sharing your project easily get the right settings out of the box. However, you may want to use an alternative mirror for a particular repository without changing the project files. Refer to <a href="./guide-mirror-settings.html"> Guide to Mirror Settings</a> for more details.</p></section><section>
<h3><a name="Profiles"></a>Profiles</h3>
-<p>Repository configuration can also be put into a profile. You can have multiple profiles, with one set to active so that you can easily switch environments. Read more about profiles in <a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a>.</p></div>
-<div class="section">
+<p>Repository configuration can also be put into a profile. You can have multiple profiles, with one set to active so that you can easily switch environments. Read more about profiles in <a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a>.</p></section><section>
<h3><a name="Optional_configuration"></a>Optional configuration</h3>
-<p>Maven will work for most tasks with the above configuration, however if you have any environmental specific configuration outside of individual projects then you will need to configure settings. The following sections refer to what is available.</p>
-<div class="section">
+<p>Maven will work for most tasks with the above configuration, however if you have any environmental specific configuration outside of individual projects then you will need to configure settings. The following sections refer to what is available.</p><section>
<h4><a name="Settings"></a>Settings</h4>
<p>Maven has a settings file located in the Maven installation and/or user home directory that configure environmental specifics such as:</p>
<ul>
@@ -233,13 +225,11 @@
<li>repository manager location</li>
<li>server authentication and passwords</li>
<li>other configuration properties</li></ul>
-<p>For information on this file, see the <a href="/settings.html">Settings reference</a></p></div>
-<div class="section">
+<p>For information on this file, see the <a href="/settings.html">Settings reference</a></p></section><section>
<h4><a name="Security"></a>Security</h4>
-<p>As of Maven 2.1.0+, you can encrypt passwords in your settings file, however you must first configure a master password. For more information on both server passwords and the master password, see the <a href="./guide-encryption.html">Guide to Password Encryption</a>.</p></div>
-<div class="section">
+<p>As of Maven 2.1.0+, you can encrypt passwords in your settings file, however you must first configure a master password. For more information on both server passwords and the master password, see the <a href="./guide-encryption.html">Guide to Password Encryption</a>.</p></section><section>
<h4><a name="Toolchains"></a>Toolchains</h4>
-<p>As of Maven 2.0.9+, you can build a project using a specific version of JDK independent from the one Maven is running with. For more information, see the <a href="./guide-using-toolchains.html">Guide to Using Toolchains</a>.</p></div></div></div>
+<p>As of Maven 2.0.9+, you can build a project using a specific version of JDK independent from the one Maven is running with. For more information, see the <a href="./guide-using-toolchains.html">Guide to Using Toolchains</a>.</p></section></section></section>
</div>
</div>
</div>
Modified: maven/website/content/guides/mini/guide-configuring-plugins.html
==============================================================================
--- maven/website/content/guides/mini/guide-configuring-plugins.html (original)
+++ maven/website/content/guides/mini/guide-configuring-plugins.html Sun Jun 9 13:59:34 2019
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from content/apt/guides/mini/guide-configuring-plugins.apt at 2019-06-09
+ | Generated by Apache Maven Doxia Site Renderer 1.9 from content/apt/guides/mini/guide-configuring-plugins.apt at 2019-06-09
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
@@ -140,7 +140,7 @@ Vincent Siveton" />
</div>
</div>
<div id="bodyColumn" class="span10" >
-<div class="section">
+<section>
<h2><a name="Guide_to_Configuring_Plug-ins"></a>Guide to Configuring Plug-ins</h2>
<ol style="list-style-type: decimal">
<li><a href="#Generic_Configuration">Generic Configuration</a>
@@ -157,25 +157,23 @@ Vincent Siveton" />
<li><a href="#Mapping_Properties">Mapping Properties</a></li></ol></li></ol></li></ol></li>
<li><a href="#Configuring_Build_Plugins">Configuring Build Plugins</a>
<ol style="list-style-type: decimal">
-<li><a href="#Using_the_executions_Tag">Using the <tt><executions></tt> Tag</a></li>
-<li><a href="#Using_the_dependencies_Tag">Using the <tt><dependencies></tt> Tag</a></li>
-<li><a href="#Using_the_inherited_Tag_In_Build_Plugins">Using the <tt><inherited></tt> Tag In Build Plugins</a></li></ol></li>
+<li><a href="#Using_the_executions_Tag">Using the <code><executions></code> Tag</a></li>
+<li><a href="#Using_the_dependencies_Tag">Using the <code><dependencies></code> Tag</a></li>
+<li><a href="#Using_the_inherited_Tag_In_Build_Plugins">Using the <code><inherited></code> Tag In Build Plugins</a></li></ol></li>
<li><a href="#Configuring_Reporting_Plugins">Configuring Reporting Plugins</a>
<ol style="list-style-type: decimal">
-<li><a href="#Using_the_reporting_Tag_VS_build_Tag">Using the <tt><reporting></tt> Tag VS <tt><build></tt> Tag</a></li>
-<li><a href="#Using_the_reportSets_Tag">Using the <tt><reportSets></tt> Tag</a></li>
-<li><a href="#Using_the_inherited_Tag_In_Reporting_Plugins">Using the <tt><inherited></tt> Tag In Reporting Plugins</a></li></ol></li></ol>
-<div class="section">
+<li><a href="#Using_the_reporting_Tag_VS_build_Tag">Using the <code><reporting></code> Tag VS <code><build></code> Tag</a></li>
+<li><a href="#Using_the_reportSets_Tag">Using the <code><reportSets></code> Tag</a></li>
+<li><a href="#Using_the_inherited_Tag_In_Reporting_Plugins">Using the <code><inherited></code> Tag In Reporting Plugins</a></li></ol></li></ol><section>
<h3><a name="Introduction"></a>Introduction</h3>
<p>In Maven, there are the build and the reporting plugins:</p>
<ul>
-<li><b>Build plugins</b> will be executed during the build and then, they should be configured in the <tt><build/></tt> element.</li>
-<li><b>Reporting plugins</b> will be executed during the site generation and they should be configured in the <tt><reporting/></tt> element.</li></ul>
-<p>All plugins should have minimal required <a href="/ref/current/maven-model/maven.html#class_plugin">information</a>: <tt>groupId</tt>, <tt>artifactId</tt> and <tt>version</tt>.</p>
-<p><b>Important Note</b>: It is recommended to always define each version of the plugins used by the build to guarantee the build reproducibility. A good practice is to specify them in the <tt><build><pluginManagement/></build></tt> elements for <b>each</b> build plugins (generally, you will define a <pluginManagement/> element in a parent POM). For reporting plugins, you should specify each version in the <tt><reporting><plugins/></reporting></tt> elements (and surely in the <tt><build><pluginManagement/></build></tt> elements too).</p></div>
-<div class="section">
+<li><b>Build plugins</b> will be executed during the build and then, they should be configured in the <code><build/></code> element.</li>
+<li><b>Reporting plugins</b> will be executed during the site generation and they should be configured in the <code><reporting/></code> element.</li></ul>
+<p>All plugins should have minimal required <a href="/ref/current/maven-model/maven.html#class_plugin">information</a>: <code>groupId</code>, <code>artifactId</code> and <code>version</code>.</p>
+<p><b>Important Note</b>: It is recommended to always define each version of the plugins used by the build to guarantee the build reproducibility. A good practice is to specify them in the <code><build><pluginManagement/></build></code> elements for <b>each</b> build plugins (generally, you will define a <pluginManagement/> element in a parent POM). For reporting plugins, you should specify each version in the <code><reporting><plugins/></reporting></code> elements (and surely in the <code><build><pluginManagement/></build></code> elements too).</p></section><section>
<h3><a name="Generic_Configuration">Generic Configuration</a></h3>
-<p>Maven plugins (build and reporting) are configured by specifying a <tt><configuration></tt> element where the child elements of the <tt><configuration></tt> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in consists of one or more Mojos where a Mojo maps to a goal). Say, for example, we had a Mojo that performed a query against a particular URL, with a specified timeout and list of options. The Mojo might look like the following:</p>
+<p>Maven plugins (build and reporting) are configured by specifying a <code><configuration></code> element where the child elements of the <code><configuration></code> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in consists of one or more Mojos where a Mojo maps to a goal). Say, for example, we had a Mojo that performed a query against a particular URL, with a specified timeout and list of options. The Mojo might look like the following:</p>
<div class="source"><pre class="prettyprint linenums">/**
* @goal query
*/
@@ -225,20 +223,17 @@ public class MyQueryMojo
</build>
...
</project></pre></div>
-<p>As you can see the elements in the configuration match the names of the fields in the Mojo. The configuration mechanism Maven employs is very similar to the way <a class="externalLink" href="http://x-stream.github.io/">XStream</a> works where elements in XML are mapped to objects. So from the example above you can see that the mapping is pretty straight forward the <tt>url</tt> element maps to the <tt>url</tt> field, the <tt>timeout</tt> element maps to the <tt>timeout</tt> field and the <tt>options</tt> element maps to the <tt>options</tt> field. The mapping mechanism can deal with arrays by inspecting the type of the field and determining if a suitable mapping is possible.</p>
-<p>For mojos that are intended to be executed directly from the CLI, their parameters usually provide a means to be configured via system properties instead of a <tt><configuration></tt> section in the POM. The plugin documentation for those parameters will list an <i>expression</i> that denotes the system properties for the configuration. In the mojo above, the parameter <tt>url</tt> is associated with the expression <tt>${query.url}</tt>, meaning its value can be specified by the system property <tt>query.url</tt> as shown below:</p>
+<p>As you can see the elements in the configuration match the names of the fields in the Mojo. The configuration mechanism Maven employs is very similar to the way <a class="externalLink" href="http://x-stream.github.io/">XStream</a> works where elements in XML are mapped to objects. So from the example above you can see that the mapping is pretty straight forward the <code>url</code> element maps to the <code>url</code> field, the <code>timeout</code> element maps to the <code>timeout</code> field and the <code>options</code> element maps to the <code>options</code> field. The mapping mechanism can deal with arrays by inspecting the type of the field and determining if a suitable mapping is possible.</p>
+<p>For mojos that are intended to be executed directly from the CLI, their parameters usually provide a means to be configured via system properties instead of a <code><configuration></code> section in the POM. The plugin documentation for those parameters will list an <i>expression</i> that denotes the system properties for the configuration. In the mojo above, the parameter <code>url</code> is associated with the expression <code>${query.url}</code>, meaning its value can be specified by the system property <code>query.url</code> as shown below:</p>
<div class="source"><pre class="prettyprint linenums">mvn myquery:query -Dquery.url=http://maven.apache.org</pre></div>
-<p>Note that the name of the system property does not necessarily match the name of the mojo parameter. While this is a rather common practice, you will often notice plugins that employ some prefix for the system properties to avoid name clashes with other system properties. Though rarely, there are also plugin parameters that (e.g. for historical reasons) employ system properties which are completely unrelated to the parameter name. So be sure to have a close look at the plugin documentation.</p>
-<div class="section">
+<p>Note that the name of the system property does not necessarily match the name of the mojo parameter. While this is a rather common practice, you will often notice plugins that employ some prefix for the system properties to avoid name clashes with other system properties. Though rarely, there are also plugin parameters that (e.g. for historical reasons) employ system properties which are completely unrelated to the parameter name. So be sure to have a close look at the plugin documentation.</p><section>
<h4><a name="Help_Goal">Help Goal</a></h4>
-<p>Recent Maven plugins have generally an <tt>help</tt> goal to have in the command line the description of the plugin, with their parameters and types. For instance, to understand the javadoc goal, you need to call:</p>
+<p>Recent Maven plugins have generally an <code>help</code> goal to have in the command line the description of the plugin, with their parameters and types. For instance, to understand the javadoc goal, you need to call:</p>
<div class="source"><pre class="prettyprint linenums">mvn javadoc:help -Ddetail -Dgoal=javadoc</pre></div>
-<p>And you will see all parameters for the javadoc:javadoc goal, similar to this <a href="/plugins/maven-javadoc-plugin/javadoc-mojo.html">page</a>.</p></div>
-<div class="section">
-<h4><a name="Configuring_Parameters">Configuring Parameters</a></h4>
-<div class="section">
+<p>And you will see all parameters for the javadoc:javadoc goal, similar to this <a href="/plugins/maven-javadoc-plugin/javadoc-mojo.html">page</a>.</p></section><section>
+<h4><a name="Configuring_Parameters">Configuring Parameters</a></h4><section>
<h5><a name="Mapping_Simple_Objects">Mapping Simple Objects</a></h5>
-<p>Mapping simple types, like Boolean or Integer, is very simple. The <tt><configuration></tt> element might look like the following:</p>
+<p>Mapping simple types, like Boolean or Integer, is very simple. The <code><configuration></code> element might look like the following:</p>
<div class="source"><pre class="prettyprint linenums">...
<configuration>
<myString>a string</myString>
@@ -248,10 +243,9 @@ public class MyQueryMojo
<myFile>c:\temp</myFile>
<myURL>http://maven.apache.org</myURL>
</configuration>
-...</pre></div></div>
-<div class="section">
+...</pre></div></section><section>
<h5><a name="Mapping_Complex_Objects">Mapping Complex Objects</a></h5>
-<p>Mapping complex types is also fairly straight forward in Maven so let's look at a simple example where we are trying to map a configuration for Person object. The <tt><configuration/></tt> element might look like the following:</p>
+<p>Mapping complex types is also fairly straight forward in Maven so let's look at a simple example where we are trying to map a configuration for Person object. The <code><configuration/></code> element might look like the following:</p>
<div class="source"><pre class="prettyprint linenums">...
<configuration>
<person>
@@ -262,9 +256,9 @@ public class MyQueryMojo
...</pre></div>
<p>The rules for mapping complex objects are as follows:</p>
<ul>
-<li>There must be a private field that corresponds to name of the element being mapped. So in our case the <tt>person</tt> element must map to a <tt>person</tt> field in the mojo.</li>
-<li>The object instantiated must be in the same package as the Mojo itself. So if your mojo is in <tt>com.mycompany.mojo.query</tt> then the mapping mechanism will look in that package for an object named <tt>Person</tt>. As you can see the mechanism will capitalize the first letter of the element name and use that to search for the object to instantiate.</li>
-<li>If you wish to have the object to be instantiated live in a different package or have a more complicated name then you must specify this using an <tt>implementation</tt> attribute like the following:</li></ul>
+<li>There must be a private field that corresponds to name of the element being mapped. So in our case the <code>person</code> element must map to a <code>person</code> field in the mojo.</li>
+<li>The object instantiated must be in the same package as the Mojo itself. So if your mojo is in <code>com.mycompany.mojo.query</code> then the mapping mechanism will look in that package for an object named <code>Person</code>. As you can see the mechanism will capitalize the first letter of the element name and use that to search for the object to instantiate.</li>
+<li>If you wish to have the object to be instantiated live in a different package or have a more complicated name then you must specify this using an <code>implementation</code> attribute like the following:</li></ul>
<div class="source"><pre class="prettyprint linenums">...
<configuration>
<person implementation="com.mycompany.mojo.query.SuperPerson">
@@ -272,11 +266,9 @@ public class MyQueryMojo
<lastName>van Zyl</lastName>
</person>
</configuration>
-...</pre></div></div>
-<div class="section">
+...</pre></div></section><section>
<h5><a name="Mapping_Collections">Mapping Collections</a></h5>
-<p>The configuration mapping mechanism can easily deal with most collections so let's go through a few examples to show you how it's done:</p>
-<div class="section">
+<p>The configuration mapping mechanism can easily deal with most collections so let's go through a few examples to show you how it's done:</p><section>
<h6><a name="Mapping_Lists">Mapping Lists</a></h6>
<p>Mapping lists works in much the same way as mapping to arrays where you a list of elements will be mapped to the List. So if you have a mojo like the following:</p>
<div class="source"><pre class="prettyprint linenums">public class MyAnimalMojo
@@ -293,7 +285,7 @@ public class MyQueryMojo
...
}
}</pre></div>
-<p>Where you have a field named <tt>animals</tt> then your configuration for the plug-in would look like the following:</p>
+<p>Where you have a field named <code>animals</code> then your configuration for the plug-in would look like the following:</p>
<div class="source"><pre class="prettyprint linenums"><project>
...
<build>
@@ -313,13 +305,12 @@ public class MyQueryMojo
</build>
...
</project></pre></div>
-<p>Where each of the animals listed would be entries in the <tt>animals</tt> field. Unlike arrays, collections have no specific component type. In order to derive the type of a list item, the following strategy is used:</p>
+<p>Where each of the animals listed would be entries in the <code>animals</code> field. Unlike arrays, collections have no specific component type. In order to derive the type of a list item, the following strategy is used:</p>
<ol style="list-style-type: decimal">
-<li>If the XML element contains an <tt>implementation</tt> hint attribute, that is used</li>
-<li>If the XML tag contains a <tt>.</tt>, try that as a fully qualified class name</li>
+<li>If the XML element contains an <code>implementation</code> hint attribute, that is used</li>
+<li>If the XML tag contains a <code>.</code>, try that as a fully qualified class name</li>
<li>Try the XML tag (with capitalized first letter) as a class in the same package as the mojo/object being configured</li>
-<li>If the element has no children, assume its type is <tt>String</tt>. Otherwise, the configuration will fail.</li></ol></div>
-<div class="section">
+<li>If the element has no children, assume its type is <code>String</code>. Otherwise, the configuration will fail.</li></ol></section><section>
<h6><a name="Mapping_Maps">Mapping Maps</a></h6>
<p>In the same way, you could define maps like the following:</p>
<div class="source"><pre class="prettyprint linenums">...
@@ -337,8 +328,7 @@ public class MyQueryMojo
<key2>value2</key2>
</myMap>
</configuration>
-...</pre></div></div>
-<div class="section">
+...</pre></div></section><section>
<h6><a name="Mapping_Properties">Mapping Properties</a></h6>
<p>Properties should be defined like the following:</p>
<div class="source"><pre class="prettyprint linenums">...
@@ -362,13 +352,11 @@ public class MyQueryMojo
<property>
</myProperties>
</configuration>
-...</pre></div></div></div></div></div>
-<div class="section">
+...</pre></div></section></section></section></section><section>
<h3><a name="Configuring_Build_Plugins">Configuring Build Plugins</a></h3>
-<p>The following is only to configure Build plugins in the <tt><build></tt> element.</p>
-<div class="section">
-<h4><a name="Using_the_.3Cexecutions.3E_Tag"></a><a name="Using_the_executions_Tag">Using the <tt><executions></tt> Tag</a></h4>
-<p>You can also configure a mojo using the <tt><executions></tt> tag. This is most commonly used for mojos that are intended to participate in some phases of the <a href="../introduction/introduction-to-the-lifecycle.html">build lifecycle</a>. Using <tt>MyQueryMojo</tt> as an example, you may have something that will look like:</p>
+<p>The following is only to configure Build plugins in the <code><build></code> element.</p><section>
+<h4><a name="Using_the_.3Cexecutions.3E_Tag"></a><a name="Using_the_executions_Tag">Using the <code><executions></code> Tag</a></h4>
+<p>You can also configure a mojo using the <code><executions></code> tag. This is most commonly used for mojos that are intended to participate in some phases of the <a href="../introduction/introduction-to-the-lifecycle.html">build lifecycle</a>. Using <code>MyQueryMojo</code> as an example, you may have something that will look like:</p>
<div class="source"><pre class="prettyprint linenums"><project>
...
<build>
@@ -414,9 +402,9 @@ public class MyQueryMojo
</build>
...
</project></pre></div>
-<p>The first execution with id "execution1" binds this configuration to the test phase. The second execution does not have a <tt><phase></tt> tag, how do you think will this execution behave? Well, goals can have a default phase binding as discussed further below. If the goal has a default phase binding then it will execute in that phase. But if the goal is not bound to any lifecycle phase then it simply won't be executed during the build lifecycle.</p>
+<p>The first execution with id "execution1" binds this configuration to the test phase. The second execution does not have a <code><phase></code> tag, how do you think will this execution behave? Well, goals can have a default phase binding as discussed further below. If the goal has a default phase binding then it will execute in that phase. But if the goal is not bound to any lifecycle phase then it simply won't be executed during the build lifecycle.</p>
<p>Note that while execution id's have to be unique among all executions of a single plugin within a POM, they don't have to be unique across an inheritance hierarchy of POMs. Executions of the same id from different POMs are merged. The same applies to executions that are defined by profiles.</p>
-<p>How about if we have a multiple executions with different phases bound to it? How do you think will it behave? Let us use the example POM above again, but this time we shall bind <tt>execution2</tt> to a phase.</p>
+<p>How about if we have a multiple executions with different phases bound to it? How do you think will it behave? Let us use the example POM above again, but this time we shall bind <code>execution2</code> to a phase.</p>
<div class="source"><pre class="prettyprint linenums"><project>
...
<build>
@@ -451,7 +439,7 @@ public class MyQueryMojo
</build>
...
</project></pre></div>
-<p>If there are multiple executions bound to different phases, then the mojo is executed once for each phase indicated. Meaning, <tt>execution1</tt> will be executed applying the configuration setup when the phase of the build is test, and <tt>execution2</tt> will be executed applying the configuration setup when the build phase is already in install.</p>
+<p>If there are multiple executions bound to different phases, then the mojo is executed once for each phase indicated. Meaning, <code>execution1</code> will be executed applying the configuration setup when the phase of the build is test, and <code>execution2</code> will be executed applying the configuration setup when the build phase is already in install.</p>
<p>Now, let us have another mojo example which shows a default lifecycle phase binding.</p>
<div class="source"><pre class="prettyprint linenums">/**
* @goal query
@@ -481,7 +469,7 @@ public class MyBindedQueryMojo
...
}
}</pre></div>
-<p>From the above mojo example, <tt>MyBindedQueryMojo</tt> is by default bound to the package phase (see the <tt>@phase</tt> notation). But if we want to execute this mojo during the install phase and not with package we can rebind this mojo into a new lifecycle phase using the <tt><phase></tt> tag under <tt><execution></tt>.</p>
+<p>From the above mojo example, <code>MyBindedQueryMojo</code> is by default bound to the package phase (see the <code>@phase</code> notation). But if we want to execute this mojo during the install phase and not with package we can rebind this mojo into a new lifecycle phase using the <code><phase></code> tag under <code><execution></code>.</p>
<div class="source"><pre class="prettyprint linenums"><project>
...
<build>
@@ -512,13 +500,12 @@ public class MyBindedQueryMojo
</build>
...
</project></pre></div>
-<p>Now, <tt>MyBindedQueryMojo</tt> default phase which is package has been overrided by install phase.</p>
-<p><b>Note:</b> Configurations inside the <tt><executions></tt> element used to differ from those that are outside <tt><executions></tt> in that they could not be used from a direct command line invocation because they were only applied when the lifecycle phase they were bound to was invoked. So you had to move a configuration section outside of the executions section to apply it globally to all invocations of the plugin. Since Maven 3.3.1 this is not the case anymore as you can specify on the command line the execution id for direct plugin goal invocation. Hence if you want to run the above plugin and it's specific execution1's configuration from the command-line, you can execute:</p>
-<div class="source"><pre class="prettyprint linenums">mvn myqyeryplugin:queryMojo@execution1</pre></div></div>
-<div class="section">
-<h4><a name="Using_the_.3Cdependencies.3E_Tag"></a><a name="Using_the_dependencies_Tag">Using the <tt><dependencies></tt> Tag</a></h4>
+<p>Now, <code>MyBindedQueryMojo</code> default phase which is package has been overrided by install phase.</p>
+<p><b>Note:</b> Configurations inside the <code><executions></code> element used to differ from those that are outside <code><executions></code> in that they could not be used from a direct command line invocation because they were only applied when the lifecycle phase they were bound to was invoked. So you had to move a configuration section outside of the executions section to apply it globally to all invocations of the plugin. Since Maven 3.3.1 this is not the case anymore as you can specify on the command line the execution id for direct plugin goal invocation. Hence if you want to run the above plugin and it's specific execution1's configuration from the command-line, you can execute:</p>
+<div class="source"><pre class="prettyprint linenums">mvn myqyeryplugin:queryMojo@execution1</pre></div></section><section>
+<h4><a name="Using_the_.3Cdependencies.3E_Tag"></a><a name="Using_the_dependencies_Tag">Using the <code><dependencies></code> Tag</a></h4>
<p>You could configure the dependencies of the Build plugins, commonly to use a more recent dependency version.</p>
-<p>For instance, the Maven Antrun Plugin version 1.2 uses Ant version 1.6.5, if you want to use the latest Ant version when running this plugin, you need to add <tt><dependencies></tt> element like the following:</p>
+<p>For instance, the Maven Antrun Plugin version 1.2 uses Ant version 1.6.5, if you want to use the latest Ant version when running this plugin, you need to add <code><dependencies></code> element like the following:</p>
<div class="source"><pre class="prettyprint linenums"><project>
...
<build>
@@ -544,10 +531,9 @@ public class MyBindedQueryMojo
</plugins>
</build>
...
-</project></pre></div></div>
-<div class="section">
-<h4><a name="Using_the_.3Cinherited.3E_Tag_In_Build_Plugins"></a><a name="Using_the_inherited_Tag_In_Build_Plugins">Using the <tt><inherited></tt> Tag In Build Plugins</a></h4>
-<p>By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could use the <tt><inherited></tt> tag:</p>
+</project></pre></div></section><section>
+<h4><a name="Using_the_.3Cinherited.3E_Tag_In_Build_Plugins"></a><a name="Using_the_inherited_Tag_In_Build_Plugins">Using the <code><inherited></code> Tag In Build Plugins</a></h4>
+<p>By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could use the <code><inherited></code> tag:</p>
<div class="source"><pre class="prettyprint linenums"><project>
...
<build>
@@ -562,21 +548,18 @@ public class MyBindedQueryMojo
</plugins>
</build>
...
-</project></pre></div></div></div>
-<div class="section">
+</project></pre></div></section></section><section>
<h3><a name="Configuring_Reporting_Plugins">Configuring Reporting Plugins</a></h3>
-<p>The following is only to configure Reporting plugins in the <tt><reporting></tt> element.</p>
-<div class="section">
-<h4><a name="Using_the_.3Creporting.3E_Tag_VS_.3Cbuild.3E_Tag"></a><a name="Using_the_reporting_Tag_VS_build_Tag">Using the <tt><reporting></tt> Tag VS <tt><build></tt> Tag</a></h4>
+<p>The following is only to configure Reporting plugins in the <code><reporting></code> element.</p><section>
+<h4><a name="Using_the_.3Creporting.3E_Tag_VS_.3Cbuild.3E_Tag"></a><a name="Using_the_reporting_Tag_VS_build_Tag">Using the <code><reporting></code> Tag VS <code><build></code> Tag</a></h4>
<p>Configuring a reporting plugin in the <reporting> or <build> elements in the pom does <b>NOT</b> have the same behavior!</p>
<dl>
-<dt><tt>mvn site</tt></dt>
-<dd>It uses <b>only</b> the parameters defined in the <configuration> element of each reporting Plugin specified in the <reporting> element, i.e. <tt>site</tt> always <b>ignores</b> the parameters defined in the <configuration> element of each plugin specified in <build>.</dd>
-<dt><tt>mvn aplugin:areportgoal</tt></dt>
-<dd>It uses <b>firstly</b> the parameters defined in the <configuration> element of each reporting Plugin specified in the <reporting> element; if a parameter is not found, it will look up to a parameter defined in the <configuration> element of each plugin specified in <build>.</dd></dl></div>
-<div class="section">
-<h4><a name="Using_the_.3CreportSets.3E_Tag"></a><a name="Using_the_reportSets_Tag">Using the <tt><reportSets></tt> Tag</a></h4>
-<p>You can configure a reporting plugin using the <tt><reportSets></tt> tag. This is most commonly used to generate reports selectively when running <tt>mvn site</tt>. The following will generate only the project team report.</p>
+<dt><code>mvn site</code></dt>
+<dd>It uses <b>only</b> the parameters defined in the <configuration> element of each reporting Plugin specified in the <reporting> element, i.e. <code>site</code> always <b>ignores</b> the parameters defined in the <configuration> element of each plugin specified in <build>.</dd>
+<dt><code>mvn aplugin:areportgoal</code></dt>
+<dd>It uses <b>firstly</b> the parameters defined in the <configuration> element of each reporting Plugin specified in the <reporting> element; if a parameter is not found, it will look up to a parameter defined in the <configuration> element of each plugin specified in <build>.</dd></dl></section><section>
+<h4><a name="Using_the_.3CreportSets.3E_Tag"></a><a name="Using_the_reportSets_Tag">Using the <code><reportSets></code> Tag</a></h4>
+<p>You can configure a reporting plugin using the <code><reportSets></code> tag. This is most commonly used to generate reports selectively when running <code>mvn site</code>. The following will generate only the project team report.</p>
<div class="source"><pre class="prettyprint linenums"><project>
...
<reporting>
@@ -605,10 +588,9 @@ public class MyBindedQueryMojo
<reports/>
</reportSet>
</reportSets></pre></div></li>
-<li>Refer to each Plugin Documentation (i.e. plugin-info.html) to know the available report goals.</li></ol></div>
-<div class="section">
-<h4><a name="Using_the_.3Cinherited.3E_Tag_In_Reporting_Plugins"></a><a name="Using_the_inherited_Tag_In_Reporting_Plugins">Using the <tt><inherited></tt> Tag In Reporting Plugins</a></h4>
-<p>Similar to the build plugins, to break the inheritance, you can use the <tt><inherited></tt> tag:</p>
+<li>Refer to each Plugin Documentation (i.e. plugin-info.html) to know the available report goals.</li></ol></section><section>
+<h4><a name="Using_the_.3Cinherited.3E_Tag_In_Reporting_Plugins"></a><a name="Using_the_inherited_Tag_In_Reporting_Plugins">Using the <code><inherited></code> Tag In Reporting Plugins</a></h4>
+<p>Similar to the build plugins, to break the inheritance, you can use the <code><inherited></code> tag:</p>
<div class="source"><pre class="prettyprint linenums"><project>
...
<reporting>
@@ -622,7 +604,7 @@ public class MyBindedQueryMojo
</plugins>
</reporting>
...
-</project></pre></div></div></div></div>
+</project></pre></div></section></section></section>
</div>
</div>
</div>
Modified: maven/website/content/guides/mini/guide-coping-with-sun-jars.html
==============================================================================
--- maven/website/content/guides/mini/guide-coping-with-sun-jars.html (original)
+++ maven/website/content/guides/mini/guide-coping-with-sun-jars.html Sun Jun 9 13:59:34 2019
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from content/apt/guides/mini/guide-coping-with-sun-jars.apt at 2019-06-09
+ | Generated by Apache Maven Doxia Site Renderer 1.9 from content/apt/guides/mini/guide-coping-with-sun-jars.apt at 2019-06-09
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
@@ -143,7 +143,7 @@
</div>
</div>
<div id="bodyColumn" class="span10" >
-<div class="section">
+<section>
<h2><a name="Coping_with_Sun_JARs"></a>Coping with Sun JARs</h2>
<p>Often users are confronted with the need to build against JARs provide by Sun like the <a class="externalLink" href="http://java.sun.com/products/javamail/">JavaMail</a> JAR, or the <a class="externalLink" href="http://java.sun.com/products/javabeans/jaf/downloads/index.html">Activation</a> JAR and users have found these JARs not present in central repository resulting in a broken build. Unfortunately most of these artifacts fall under Sun's Binary License which disallows us from distributing them from Ibiblio.</p>
<p>Another problem is that Sun's appears not to have any sort of convention for naming their own JARs so we have taken steps in suggesting some common names for Sun's artifacts. You can find a list of our suggestions here:</p>
@@ -237,7 +237,7 @@
<layout>default</layout>
</repository>
</repositories>
-...</pre></div></div>
+...</pre></div></section>
</div>
</div>
</div>
Modified: maven/website/content/guides/mini/guide-creating-archetypes.html
==============================================================================
--- maven/website/content/guides/mini/guide-creating-archetypes.html (original)
+++ maven/website/content/guides/mini/guide-creating-archetypes.html Sun Jun 9 13:59:34 2019
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from content/apt/guides/mini/guide-creating-archetypes.apt at 2019-06-09
+ | Generated by Apache Maven Doxia Site Renderer 1.9 from content/apt/guides/mini/guide-creating-archetypes.apt at 2019-06-09
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
@@ -139,18 +139,17 @@
</div>
</div>
<div id="bodyColumn" class="span10" >
-<div class="section">
+<section>
<h2><a name="Guide_to_Creating_Archetypes"></a>Guide to Creating Archetypes</h2>
<p>Creating an archetype is a pretty straight forward process. An archetype is a very simple artifact, that contains the project prototype you wish to create. An archetype is made up of:</p>
<ul>
-<li>an <a href="/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html">archetype descriptor</a> (<tt>archetype-metadata.xml</tt> in directory: <tt>src/main/resources/META-INF/maven/</tt>). It lists all the files that will be contained in the archetype and categorizes them so they can be processed correctly by the archetype generation mechanism.</li>
-<li>the prototype files that are copied by the archetype plugin (directory: <tt>src/main/resources/archetype-resources/</tt>)</li>
-<li>the prototype pom (<tt>pom.xml</tt> in: <tt>src/main/resources/archetype-resources</tt>)</li>
-<li>a pom for the archetype (<tt>pom.xml</tt> in the archetype's root directory).</li></ul>
-<p>To create an archetype follow these steps:</p>
-<div class="section">
+<li>an <a href="/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html">archetype descriptor</a> (<code>archetype-metadata.xml</code> in directory: <code>src/main/resources/META-INF/maven/</code>). It lists all the files that will be contained in the archetype and categorizes them so they can be processed correctly by the archetype generation mechanism.</li>
+<li>the prototype files that are copied by the archetype plugin (directory: <code>src/main/resources/archetype-resources/</code>)</li>
+<li>the prototype pom (<code>pom.xml</code> in: <code>src/main/resources/archetype-resources</code>)</li>
+<li>a pom for the archetype (<code>pom.xml</code> in the archetype's root directory).</li></ul>
+<p>To create an archetype follow these steps:</p><section>
<h3><a name="a1._Create_a_new_project_and_pom.xml_for_the_archetype_artifact"></a>1. Create a new project and pom.xml for the archetype artifact</h3>
-<p>An example <tt>pom.xml</tt> for an archetype artifact looks as follows:</p>
+<p>An example <code>pom.xml</code> for an archetype artifact looks as follows:</p>
<div class="source"><pre class="prettyprint linenums">
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -162,10 +161,9 @@
<packaging>maven-archetype</packaging>
</project>
</pre></div>
-<p>All you need to specify is a <tt>groupId</tt>, <tt>artifactId</tt> and <tt>version</tt>. These three parameters will be needed later for invoking the archetype via <tt>archetype:generate</tt> from the commandline.</p></div>
-<div class="section">
+<p>All you need to specify is a <code>groupId</code>, <code>artifactId</code> and <code>version</code>. These three parameters will be needed later for invoking the archetype via <code>archetype:generate</code> from the commandline.</p></section><section>
<h3><a name="a2._Create_the_archetype_descriptor"></a>2. Create the archetype descriptor</h3>
-<p>The <a href="/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html">archetype descriptor</a> is a file called <tt>archetype-metadata.xml</tt> which must be located in the <tt>src/main/resources/META-INF/maven/</tt> directory. An example of an archetype descriptor can be found in the quickstart archetype:</p>
+<p>The <a href="/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html">archetype descriptor</a> is a file called <code>archetype-metadata.xml</code> which must be located in the <code>src/main/resources/META-INF/maven/</code> directory. An example of an archetype descriptor can be found in the quickstart archetype:</p>
<div class="source"><pre class="prettyprint linenums">
<archetype-descriptor
xsi:schemaLocation="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0
@@ -183,13 +181,13 @@
</fileSets>
</archetype-descriptor>
</pre></div>
-<p>The attribute <tt>name</tt> tag should be the same as the <tt>artifactId</tt> in the archetype <tt>pom.xml</tt>.</p>
-<p>The boolean attribute <tt>partial</tt> show if this archetype is representing a full Maven project or only parts.</p>
-<p>The <tt>requiredProperties</tt>, <tt>fileSets</tt> and <tt>modules</tt> tags represent the differents parts of the project:</p>
+<p>The attribute <code>name</code> tag should be the same as the <code>artifactId</code> in the archetype <code>pom.xml</code>.</p>
+<p>The boolean attribute <code>partial</code> show if this archetype is representing a full Maven project or only parts.</p>
+<p>The <code>requiredProperties</code>, <code>fileSets</code> and <code>modules</code> tags represent the differents parts of the project:</p>
<ul>
-<li><tt><requiredProperties></tt> : List of required properties to generate a project from this archetype</li>
-<li><tt><fileSets></tt> : File sets definition</li>
-<li><tt><modules></tt> : Modules definition</li></ul>
+<li><code><requiredProperties></code> : List of required properties to generate a project from this archetype</li>
+<li><code><fileSets></code> : File sets definition</li>
+<li><code><modules></code> : Modules definition</li></ul>
<p>At this point one can only specify individual files to be created but not empty directories.</p>
<p>Thus the quickstart archetype shown above defines the following directory structure:</p>
<div class="source"><pre class="prettyprint linenums">
@@ -210,11 +208,10 @@ archetype
`-- test
`-- java
`-- AppTest.java
-</pre></div></div>
-<div class="section">
+</pre></div></section><section>
<h3><a name="a3._Create_the_prototype_files_and_the_prototype_pom.xml"></a>3. Create the prototype files and the prototype pom.xml</h3>
-<p>The next component of the archetype to be created is the prototype <tt>pom.xml</tt>. Any <tt>pom.xml</tt> will do, just don't forget to the set <tt>artifactId</tt> and <tt>groupId</tt> as variables ( <tt>${artifactId}</tt> / <tt>${groupId}</tt> ). Both variables will be initialized from the commandline when calling <tt>archetype:generate</tt>.</p>
-<p>An example for a prototype <tt>pom.xml</tt> is:</p>
+<p>The next component of the archetype to be created is the prototype <code>pom.xml</code>. Any <code>pom.xml</code> will do, just don't forget to the set <code>artifactId</code> and <code>groupId</code> as variables ( <code>${artifactId}</code> / <code>${groupId}</code> ). Both variables will be initialized from the commandline when calling <code>archetype:generate</code>.</p>
+<p>An example for a prototype <code>pom.xml</code> is:</p>
<div class="source"><pre class="prettyprint linenums">
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -237,14 +234,13 @@ archetype
</dependency>
</dependencies>
</project>
-</pre></div></div>
-<div class="section">
+</pre></div></section><section>
<h3><a name="a4._Install_the_archetype_and_run_the_archetype_plugin"></a>4. Install the archetype and run the archetype plugin</h3>
<p>Now you are ready to install the archetype:</p>
<div class="source"><pre class="prettyprint linenums">
mvn install
</pre></div>
-<p>Now that you have created an archetype, you can try it on your local system by using the following command. In this command, you need to specify the full information about the archetype you want to use (its <tt>groupId</tt>, its <tt>artifactId</tt>, its <tt>version</tt>) and the information about the new project you want to create (<tt>artifactId</tt> and <tt>groupId</tt>). Don't forget to include the version of your archetype (if you don't include the version, you archetype creation may fail with a message that version:RELEASE was not found)</p>
+<p>Now that you have created an archetype, you can try it on your local system by using the following command. In this command, you need to specify the full information about the archetype you want to use (its <code>groupId</code>, its <code>artifactId</code>, its <code>version</code>) and the information about the new project you want to create (<code>artifactId</code> and <code>groupId</code>). Don't forget to include the version of your archetype (if you don't include the version, you archetype creation may fail with a message that version:RELEASE was not found)</p>
<div class="source"><pre class="prettyprint linenums">
mvn archetype:generate \
-DarchetypeGroupId=<archetype-groupId> \
@@ -253,8 +249,7 @@ mvn archetype:generate
-DgroupId=<my.groupid> \
-DartifactId=<my-artifactId>
</pre></div>
-<p>Once you are happy with the state of your archetype, you can deploy (or submit it to <a href="/guides/mini/guide-central-repository-upload.html">Maven Central</a>) it as any other artifact and the archetype will then be available to any user of Maven.</p></div>
-<div class="section">
+<p>Once you are happy with the state of your archetype, you can deploy (or submit it to <a href="/guides/mini/guide-central-repository-upload.html">Maven Central</a>) it as any other artifact and the archetype will then be available to any user of Maven.</p></section><section>
<h3><a name="Alternative_way_to_start_creating_your_Archetype"></a>Alternative way to start creating your Archetype</h3>
<p>Instead of manually creating the directory structure needed for an archetype, simply use</p>
<div class="source"><pre class="prettyprint linenums">mvn archetype:generate
@@ -262,7 +257,7 @@ mvn archetype:generate
-DartifactId=[your project's artifact id]
-DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-archetype</pre></div>
-<p>Afterwhich, you can now customize the contents of the <tt>archetype-resources</tt> directory, and <tt>archetype-metadata.xml</tt>, then, proceed to Step#4 (Install the archetype and run the archetype plugin).</p></div></div>
+<p>Afterwhich, you can now customize the contents of the <code>archetype-resources</code> directory, and <code>archetype-metadata.xml</code>, then, proceed to Step#4 (Install the archetype and run the archetype plugin).</p></section></section>
</div>
</div>
</div>
Modified: maven/website/content/guides/mini/guide-default-execution-ids.html
==============================================================================
--- maven/website/content/guides/mini/guide-default-execution-ids.html (original)
+++ maven/website/content/guides/mini/guide-default-execution-ids.html Sun Jun 9 13:59:34 2019
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from content/apt/guides/mini/guide-default-execution-ids.apt at 2019-06-09
+ | Generated by Apache Maven Doxia Site Renderer 1.9 from content/apt/guides/mini/guide-default-execution-ids.apt at 2019-06-09
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
@@ -160,7 +160,7 @@
</div>
</div>
<div id="bodyColumn" class="span10" >
-<div class="section">
+<section>
<h2><a name="Guide_to_Configuring_Default_Mojo_Executions"></a>Guide to Configuring Default Mojo Executions</h2>
<p>In most cases where you need to configure a plugin, there are two options that work well: plugin-level configuration and execution-level configuration. Plugin-level configuration is the most common method for configuring plugins that will be used from the command line, are defined as part of the default lifecycle, or that use a common configuration across all invocations. In fact, for direct invocation from the command line, plugin-level configuration has been the <i>only</i> option historically.</p>
<p>On the other hand, in cases where a more advanced build process requires the execution of mojos - sometimes the same mojos, sometimes different ones - from a single plugin that use different configurations, the execution-level configuration is most commonly used. These cases normally involve plugins that are introduced as part of the standard build process, but which aren't present in the default lifecycle mapping for that particular packaging. In these cases, common settings shared between executions are still normally specified in the plugin-level configuration.</p>
@@ -169,13 +169,11 @@
<li>Mojos run from the command line <i>and</i> during the build, when the CLI-driven invocation requires its own configuration.</li>
<li>Mojo executions that are bound to the lifecycle as part of the default mapping for a particular packaging, especially in cases where the same mojos need to be added to a second execution with different configuration.</li>
<li>Groups of mojos from the same plugin that are bound to the lifecycle as part of the default mapping for a particular packaging, but require separate configurations.</li></ul>
-<p>Originally, the default value of the executionId - literally set to <tt>default</tt> in the POM model - was meant to provide some of this functionality. Unfortunately, this solution was never tested to make sure it worked with the use cases above; they fell through the cracks during testing. Now, with the release of Maven 2.2.0 (and later, Maven 3.0), these use cases can finally be addressed.</p>
-<div class="section">
-<h3><a name="Default_executionIds_for_Implied_Executions"></a>Default <tt>executionId</tt>s for Implied Executions</h3>
-<p>When you consider the fact that the aforementioned configuration use cases are for mojos that are not explicitly mentioned in the POM, it's reasonable to refer to them as implied executions. But if they're implied, how can Maven allow users to provide configuration for them? The solution we've implemented is rather simple and low-tech, but should be more than adequate to handle even advanced use cases. Starting in Maven 2.2.0, each mojo invoked directly from the command line will have an execution Id of <tt>default-cli</tt> assigned to it, which will allow the configuration of that execution from the POM by using this default execution Id. Likewise, each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of <tt>default-<goalName></tt> assigned to it, to allow configuration of each default mojo execution independently.</p>
-<div class="section">
+<p>Originally, the default value of the executionId - literally set to <code>default</code> in the POM model - was meant to provide some of this functionality. Unfortunately, this solution was never tested to make sure it worked with the use cases above; they fell through the cracks during testing. Now, with the release of Maven 2.2.0 (and later, Maven 3.0), these use cases can finally be addressed.</p><section>
+<h3><a name="Default_executionIds_for_Implied_Executions"></a>Default <code>executionId</code>s for Implied Executions</h3>
+<p>When you consider the fact that the aforementioned configuration use cases are for mojos that are not explicitly mentioned in the POM, it's reasonable to refer to them as implied executions. But if they're implied, how can Maven allow users to provide configuration for them? The solution we've implemented is rather simple and low-tech, but should be more than adequate to handle even advanced use cases. Starting in Maven 2.2.0, each mojo invoked directly from the command line will have an execution Id of <code>default-cli</code> assigned to it, which will allow the configuration of that execution from the POM by using this default execution Id. Likewise, each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of <code>default-<goalName></code> assigned to it, to allow configuration of each default mojo execution independently.</p><section>
<h4><a name="Example:_Command-line_variant_invocation_of_the_assembly_plugin"></a>Example: Command-line variant invocation of the assembly plugin</h4>
-<p>Consider the case where the user wants to execute the <tt>assembly:assembly</tt> mojo directly on the command line, but already has a configuration for the <tt>assembly:single</tt> mojo that runs during the main build lifecycle. Since these configurations require different options, the user cannot use the plugin-level configuration section to specify common elements.</p>
+<p>Consider the case where the user wants to execute the <code>assembly:assembly</code> mojo directly on the command line, but already has a configuration for the <code>assembly:single</code> mojo that runs during the main build lifecycle. Since these configurations require different options, the user cannot use the plugin-level configuration section to specify common elements.</p>
<p>In this case, the assembly-plugin configuration might look like this:</p>
<div class="source"><pre class="prettyprint linenums"><plugin>
<artifactId>maven-assembly-plugin</artifactId>
@@ -207,12 +205,11 @@
</execution>
</executions>
</plugin></pre></div>
-<p>In the above example, you can see several interesting things. First, the main build process will invoke the <tt>assembly:single</tt> mojo during the <tt>package</tt> phase of the build, and produce both binary and source distribution artifacts using custom assembly descriptors included with the project. Second, all invocations of the assembly plugin should use a <tt>tarLongFileMode</tt> strategy of <tt>gnu</tt>. Finally, when the assembly plugin is invoked from the command line, it will build the standard <tt>jar-with-dependencies</tt> and <tt>project</tt> artifacts for the project, and ignore the custom assembly descriptors in <tt>src/main/assembly</tt>.</p>
-<p>Now, notice the difference in the way the two execution blocks reference assembly descriptors. One uses custom descriptors via the <tt>descriptors</tt> section, and the other uses standard descriptors via the <tt>descriptorRefs</tt> section. These two sections cannot override one another, so it's impossible to setup one section - say, <tt>descriptorRefs</tt> - in the plugin-level configuration block (to provide CLI access to it, as historical versions of Maven would require), then have the <tt>build-distros</tt> invocation override it with the custom descriptors specified in the <tt>descriptors</tt> section. This configuration is not possible in versions of Maven before 2.2.0.</p></div>
-<div class="section">
-<h4><a name="Example:_Configuring_compile_to_run_twice"></a>Example: Configuring <tt>compile</tt> to run twice</h4>
-<p>In this scenario, the user wants to run the <tt>compiler:compile</tt> mojo twice for his <tt>jar</tt> packaging project. The main reason for this is to provide an entry point into the application that will warn the user if he's using a Java version older than 1.5, then exit gracefully. Without such an entry point, the user would be confronted with a stacktrace in the event he tried to run this application with a 1.4 or older JRE.</p>
-<p>Therefore, the user needs to compile tha bulk of his application to target the 1.5 Java specification, then compile the rest (the entry point) to target an older specification...say, 1.3. The first execution will specify the <tt>source</tt> and <tt>target</tt> values at <tt>1.5</tt>, and add an <tt>excludes</tt> section to avoid compiling the entry point for the application. The second pass will then re-specify <tt>source</tt> and <tt>target</tt> to <tt>1.3</tt>, and basically invert the original <tt>excludes</tt> section to be an <tt>includes</tt> section, so as to compile <i>only</i> the entry point class.</p>
+<p>In the above example, you can see several interesting things. First, the main build process will invoke the <code>assembly:single</code> mojo during the <code>package</code> phase of the build, and produce both binary and source distribution artifacts using custom assembly descriptors included with the project. Second, all invocations of the assembly plugin should use a <code>tarLongFileMode</code> strategy of <code>gnu</code>. Finally, when the assembly plugin is invoked from the command line, it will build the standard <code>jar-with-dependencies</code> and <code>project</code> artifacts for the project, and ignore the custom assembly descriptors in <code>src/main/assembly</code>.</p>
+<p>Now, notice the difference in the way the two execution blocks reference assembly descriptors. One uses custom descriptors via the <code>descriptors</code> section, and the other uses standard descriptors via the <code>descriptorRefs</code> section. These two sections cannot override one another, so it's impossible to setup one section - say, <code>descriptorRefs</code> - in the plugin-level configuration block (to provide CLI access to it, as historical versions of Maven would require), then have the <code>build-distros</code> invocation override it with the custom descriptors specified in the <code>descriptors</code> section. This configuration is not possible in versions of Maven before 2.2.0.</p></section><section>
+<h4><a name="Example:_Configuring_compile_to_run_twice"></a>Example: Configuring <code>compile</code> to run twice</h4>
+<p>In this scenario, the user wants to run the <code>compiler:compile</code> mojo twice for his <code>jar</code> packaging project. The main reason for this is to provide an entry point into the application that will warn the user if he's using a Java version older than 1.5, then exit gracefully. Without such an entry point, the user would be confronted with a stacktrace in the event he tried to run this application with a 1.4 or older JRE.</p>
+<p>Therefore, the user needs to compile tha bulk of his application to target the 1.5 Java specification, then compile the rest (the entry point) to target an older specification...say, 1.3. The first execution will specify the <code>source</code> and <code>target</code> values at <code>1.5</code>, and add an <code>excludes</code> section to avoid compiling the entry point for the application. The second pass will then re-specify <code>source</code> and <code>target</code> to <code>1.3</code>, and basically invert the original <code>excludes</code> section to be an <code>includes</code> section, so as to compile <i>only</i> the entry point class.</p>
<p>The resulting configuration might look something like this:</p>
<div class="source"><pre class="prettyprint linenums"><plugin>
<artifactId>maven-compiler-plugin</artifactId>
@@ -247,13 +244,12 @@
</plugin></pre></div>
<p>There are three important things to notice in the above compiler-plugin configuration:</p>
<ul>
-<li>The default <tt>source</tt> and <tt>target</tt> compatibility levels are for Java 1.5. This means that the compiler will generate binaries for Java 1.5 from both the main codebase and the test codebase, unless otherwise overridden.</li>
-<li>The default pass of the <tt>compile</tt> goal will <i>exclude</i> the <tt>**/cli/*</tt> path pattern, but will compile everything else in <tt>src/main/java</tt> to run under Java 1.5.</li>
-<li>The second pass of the <tt>compile</tt> mojo - in the execution called <tt>build-java14-cli</tt> - resets the <tt>source</tt> and <tt>target</tt> versions to <tt>1.3</tt>, and inverts the exclude rule from the first pass. This means the second time around, the compiler will produce 1.4-targeted binaries for the classes matching the <tt>**/cli/*</tt> path pattern.</li></ul>
-<p>Note that prior to Maven 2.2.0, it was much more difficult - if not impossible - to compile different subpaths within your project's codebase to target different Java versions.</p></div>
-<div class="section">
-<h4><a name="Example:_Configuring_compile_and_testCompile_mojos_separately"></a>Example: Configuring <tt>compile</tt> and <tt>testCompile</tt> mojos separately</h4>
-<p>Finally, building on our use of the compiler plugin to tease out these different use cases, consider the case where a user wants to target version 1.4 of the Java specification as his runtime platform. However, he still wants the convenience and other advantages to be found in a unit-testing framework like TestNG. This forces the user to configure the <tt>compile</tt> mojo with one set of <tt>source</tt> and <tt>target</tt> values - specifically, <tt>1.4</tt> - and the <tt>testCompile</tt> mojo with another (<tt>1.5</tt>).</p>
+<li>The default <code>source</code> and <code>target</code> compatibility levels are for Java 1.5. This means that the compiler will generate binaries for Java 1.5 from both the main codebase and the test codebase, unless otherwise overridden.</li>
+<li>The default pass of the <code>compile</code> goal will <i>exclude</i> the <code>**/cli/*</code> path pattern, but will compile everything else in <code>src/main/java</code> to run under Java 1.5.</li>
+<li>The second pass of the <code>compile</code> mojo - in the execution called <code>build-java14-cli</code> - resets the <code>source</code> and <code>target</code> versions to <code>1.3</code>, and inverts the exclude rule from the first pass. This means the second time around, the compiler will produce 1.4-targeted binaries for the classes matching the <code>**/cli/*</code> path pattern.</li></ul>
+<p>Note that prior to Maven 2.2.0, it was much more difficult - if not impossible - to compile different subpaths within your project's codebase to target different Java versions.</p></section><section>
+<h4><a name="Example:_Configuring_compile_and_testCompile_mojos_separately"></a>Example: Configuring <code>compile</code> and <code>testCompile</code> mojos separately</h4>
+<p>Finally, building on our use of the compiler plugin to tease out these different use cases, consider the case where a user wants to target version 1.4 of the Java specification as his runtime platform. However, he still wants the convenience and other advantages to be found in a unit-testing framework like TestNG. This forces the user to configure the <code>compile</code> mojo with one set of <code>source</code> and <code>target</code> values - specifically, <code>1.4</code> - and the <code>testCompile</code> mojo with another (<code>1.5</code>).</p>
<p>The resulting compiler-plugin configuration might look something like the following:</p>
<div class="source"><pre class="prettyprint linenums"><plugin>
<artifactId>maven-compiler-plugin</artifactId>
@@ -274,9 +270,9 @@
</execution>
</executions>
</plugin></pre></div>
-<p>This example is fairly simple and straightforward. First, the <tt>default-compile</tt> execution sets the <tt>source</tt> and <tt>target</tt> values to <tt>1.3</tt> to allow older Java versions to run the project. Then, the <tt>default-testCompile</tt> execution resets the <tt>source</tt> and <tt>target</tt> values to <tt>1.5</tt>, which enables the project to use tools like TestNG that use annotations.</p>
-<p>Incidentally, it's perhaps useful to point out that the example above is a little bit contrived; the compiler plugin targets Java 1.3 by default, so the only configuration that's really required is the <tt>default-testCompile</tt> execution. The <tt>default-compile</tt> execution respecifies plugin defaults. The only time this might be useful is when a parent POM defines a plugin-level configuration for <tt>source</tt> and <tt>target</tt> that needs to be changed for the purposes of these different compiler executions. This example is meant to be illustrative of the potential for separate configuration of default lifecycle mojos to be found in Maven 2.2.0.</p>
-<p>Again, the above configuration would not be possible in older versions of Maven. Starting with Maven 2.2.0, these advanced configurations have become a reality.</p></div></div></div>
+<p>This example is fairly simple and straightforward. First, the <code>default-compile</code> execution sets the <code>source</code> and <code>target</code> values to <code>1.3</code> to allow older Java versions to run the project. Then, the <code>default-testCompile</code> execution resets the <code>source</code> and <code>target</code> values to <code>1.5</code>, which enables the project to use tools like TestNG that use annotations.</p>
+<p>Incidentally, it's perhaps useful to point out that the example above is a little bit contrived; the compiler plugin targets Java 1.3 by default, so the only configuration that's really required is the <code>default-testCompile</code> execution. The <code>default-compile</code> execution respecifies plugin defaults. The only time this might be useful is when a parent POM defines a plugin-level configuration for <code>source</code> and <code>target</code> that needs to be changed for the purposes of these different compiler executions. This example is meant to be illustrative of the potential for separate configuration of default lifecycle mojos to be found in Maven 2.2.0.</p>
+<p>Again, the above configuration would not be possible in older versions of Maven. Starting with Maven 2.2.0, these advanced configurations have become a reality.</p></section></section></section>
</div>
</div>
</div>