Modified: 
maven/website/content/guides/introduction/introduction-to-the-lifecycle.html
==============================================================================
--- 
maven/website/content/guides/introduction/introduction-to-the-lifecycle.html 
(original)
+++ 
maven/website/content/guides/introduction/introduction-to-the-lifecycle.html 
Sat Aug 20 12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/introduction/introduction-to-the-lifecycle.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/introduction/introduction-to-the-lifecycle.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Brett Porter" />
     <meta name="date" content="2006-06-16
 2015-04-04" />
@@ -147,8 +147,8 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Introduction_to_the_Build_Lifecycle"></a>Introduction to the 
Build Lifecycle</h2><section>
-<h3><a name="Table_Of_Contents"></a>Table Of Contents</h3>
+<h1><a name="Introduction_to_the_Build_Lifecycle"></a>Introduction to the 
Build Lifecycle</h1><section>
+<h2><a name="Table_Of_Contents"></a>Table Of Contents</h2>
 <ul>
 <li><a href="#Build_Lifecycle_Basics">Build Lifecycle Basics</a></li>
 <li><a href="#Setting_Up_Your_Project_to_Use_the_Build_Lifecycle">Setting Up 
Your Project to Use the Build Lifecycle</a>
@@ -157,11 +157,11 @@
 <li><a href="#Plugins">Plugins</a></li></ul></li>
 <li><a href="#Lifecycle_Reference">Lifecycle Reference</a></li>
 <li><a href="#Built-in_Lifecycle_Bindings">Built-in Lifecycle 
Bindings</a></li></ul></section><section>
-<h3><a name="Build_Lifecycle_Basics">Build Lifecycle Basics</a></h3>
+<h2><a name="Build_Lifecycle_Basics">Build Lifecycle Basics</a></h2>
 <p>Maven is based around the central concept of a build lifecycle. What this 
means is that the process for building and distributing a particular artifact 
(project) is clearly defined.</p>
 <p>For the person building a project, this means that it is only necessary to 
learn a small set of commands to build any Maven project, and the <a 
href="./introduction-to-the-pom.html">POM</a> will ensure they get the results 
they desired.</p>
 <p>There are three built-in build lifecycles: default, clean and site. The 
<code>default</code> lifecycle handles your project deployment, the 
<code>clean</code> lifecycle handles project cleaning, while the 
<code>site</code> lifecycle handles the creation of your project's web 
site.</p><section>
-<h4><a name="A_Build_Lifecycle_is_Made_Up_of_Phases">A Build Lifecycle is Made 
Up of Phases</a></h4>
+<h3><a name="A_Build_Lifecycle_is_Made_Up_of_Phases">A Build Lifecycle is Made 
Up of Phases</a></h3>
 <p>Each of these build lifecycles is defined by a different list of build 
phases, wherein a build phase represents a stage in the lifecycle.</p>
 <p>For example, the default lifecycle comprises of the following phases (for a 
complete list of the lifecycle phases, refer to the <a 
href="#Lifecycle_Reference">Lifecycle Reference</a>):</p>
 <ul>
@@ -174,7 +174,7 @@
 <li><code>deploy</code> - done in the build environment, copies the final 
package to the remote repository for sharing with other developers and 
projects.</li></ul>
 <p>These lifecycle phases (plus the other lifecycle phases not shown here) are 
executed sequentially to complete the <code>default</code> lifecycle. Given the 
lifecycle phases above, this means that when the default lifecycle is used, 
Maven will first validate the project, then will try to compile the sources, 
run those against the tests, package the binaries (e.g. jar), run integration 
tests against that package, verify the integration tests, install the verified 
package to the local repository, then deploy the installed package to a remote 
repository.</p>
 <p><i><a 
href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></section><section>
-<h4><a name="Usual_Command_Line_Calls">Usual Command Line Calls</a></h4>
+<h3><a name="Usual_Command_Line_Calls">Usual Command Line Calls</a></h3>
 <p>You should select the phase that matches your outcome. If you want your 
jar, run <code>package</code>. If you want to run the unit tests, run 
<code>test</code>.</p>
 <p>If you are uncertain what you want, the preferred phase to call is</p>
 <div>
@@ -185,7 +185,7 @@
 <pre>mvn clean deploy</pre></div>
 <p>The same command can be used in a multi-module scenario (i.e. a project 
with one or more subprojects). Maven traverses into every subproject and 
executes <code>clean</code>, then executes <code>deploy</code> (including all 
of the prior build phase steps).</p>
 <p><i><a 
href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></section><section>
-<h4><a name="A_Build_Phase_is_Made_Up_of_Plugin_Goals">A Build Phase is Made 
Up of Plugin Goals</a></h4>
+<h3><a name="A_Build_Phase_is_Made_Up_of_Plugin_Goals">A Build Phase is Made 
Up of Plugin Goals</a></h3>
 <p>However, even though a build phase is responsible for a specific step in 
the build lifecycle, the manner in which it carries out those responsibilities 
may vary. And this is done by declaring the plugin goals bound to those build 
phases.</p>
 <p>A plugin goal represents a specific task (finer than a build phase) which 
contributes to the building and managing of a project. It may be bound to zero 
or more build phases. A goal not bound to any build phase could be executed 
outside of the build lifecycle by direct invocation. The order of execution 
depends on the order in which the goal(s) and the build phase(s) are invoked. 
For example, consider the command below. The <code>clean</code> and 
<code>package</code> arguments are build phases, while the 
<code>dependency:copy-dependencies</code> is a goal (of a plugin).</p>
 <div>
@@ -195,14 +195,14 @@
 <p>Furthermore, a build phase can also have zero or more goals bound to it. If 
a build phase has no goals bound to it, that build phase will not execute. But 
if it has one or more goals bound to it, it will execute all those goals.</p>
 <p>(<i>Note: In Maven 2.0.5 and above, multiple goals bound to a phase are 
executed in the same order as they are declared in the POM, however multiple 
instances of the same plugin are not supported. Multiple instances of the same 
plugin are grouped to execute together and ordered in Maven 2.0.11 and 
above</i>).</p>
 <p><i><a 
href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></section><section>
-<h4><a name="Some_Phases_Are_Not_Usually_Called_From_the_Command_Line">Some 
Phases Are Not Usually Called From the Command Line</a></h4>
+<h3><a name="Some_Phases_Are_Not_Usually_Called_From_the_Command_Line">Some 
Phases Are Not Usually Called From the Command Line</a></h3>
 <p>The phases named with hyphenated-words (<code>pre-*</code>, 
<code>post-*</code>, or <code>process-*</code>) are not usually directly called 
from the command line. These phases sequence the build, producing intermediate 
results that are not useful outside the build. In the case of invoking 
<code>integration-test</code>, the environment may be left in a hanging 
state.</p>
 <p>Code coverage tools such as Jacoco and execution container plugins such as 
Tomcat, Cargo, and Docker bind goals to the <code>pre-integration-test</code> 
phase to prepare the integration test container environment. These plugins also 
bind goals to the <code>post-integration-test</code> phase to collect coverage 
statistics or decommission the integration test container.</p>
 <p>Failsafe and code coverage plugins bind goals to 
<code>integration-test</code> and <code>verify</code> phases. The net result is 
test and coverage reports are available after the <code>verify</code> phase. If 
<code>integration-test</code> were to be called from the command line, no 
reports are generated. Worse is that the integration test container environment 
is left in a hanging state; the Tomcat webserver or Docker instance is left 
running, and Maven may not even terminate by itself.</p>
 <p><i><a 
href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></section></section><section>
-<h3><a name="Setting_Up_Your_Project_to_Use_the_Build_Lifecycle">Setting Up 
Your Project to Use the Build Lifecycle</a></h3>
+<h2><a name="Setting_Up_Your_Project_to_Use_the_Build_Lifecycle">Setting Up 
Your Project to Use the Build Lifecycle</a></h2>
 <p>The build lifecycle is simple enough to use, but when you are constructing 
a Maven build for a project, how do you go about assigning tasks to each of 
those build phases?</p><section>
-<h4><a name="Packaging">Packaging</a></h4>
+<h3><a name="Packaging">Packaging</a></h3>
 <p>The first, and most common way, is to set the packaging for your project 
via the equally named POM element <code>&lt;packaging&gt;</code>. Some of the 
valid packaging values are <code>jar</code>, <code>war</code>, <code>ear</code> 
and <code>pom</code>. If no packaging value has been specified, it will default 
to <code>jar</code>.</p>
 <p>Each packaging contains a list of goals to bind to a particular phase. For 
example, the <code>jar</code> packaging will bind the following goals to build 
phases of the default lifecycle.</p>
 <table border="1" class="table table-striped">
@@ -236,7 +236,7 @@
 <p>This is an almost <a 
href="/ref/current/maven-core/default-bindings.html">standard set of 
bindings</a>; however, some packagings handle them differently. For example, a 
project that is purely metadata (packaging value is <code>pom</code>) only 
binds goals to the <code>install</code> and <code>deploy</code> phases (for a 
complete list of goal-to-build-phase bindings of some of the packaging types, 
refer to the <a href="#Lifecycle_Reference">Lifecycle Reference</a>).</p>
 <p>Note that for some packaging types to be available, you may also need to 
include a particular plugin in the <code>&lt;build&gt;</code> section of your 
POM and specify <code>&lt;extensions&gt;true&lt;/extensions&gt;</code> for that 
plugin. One example of a plugin that requires this is the Plexus plugin, which 
provides a <code>plexus-application</code> and <code>plexus-service</code> 
packaging.</p>
 <p><i><a 
href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></section><section>
-<h4><a name="Plugins">Plugins</a></h4>
+<h3><a name="Plugins">Plugins</a></h3>
 <p>The second way to add goals to phases is to configure plugins in your 
project. Plugins are artifacts that provide goals to Maven. Furthermore, a 
plugin may have one or more goals wherein each goal represents a capability of 
that plugin. For example, the Compiler plugin has two goals: 
<code>compile</code> and <code>testCompile</code>. The former compiles the 
source code of your main code, while the latter compiles the source code of 
your test code.</p>
 <p>As you will see in the later sections, plugins can contain information that 
indicates which lifecycle phase to bind a goal to. Note that adding the plugin 
on its own is not enough information - you must also specify the goals you want 
to run as part of your build.</p>
 <p>The goals that are configured will be added to the goals already bound to 
the lifecycle from the packaging selected. If more than one goal is bound to a 
particular phase, the order used is that those from the packaging are executed 
first, followed by those configured in the POM. Note that you can use the 
<code>&lt;executions&gt;</code> element to gain more control over the order of 
particular goals.</p>
@@ -282,9 +282,9 @@
  &lt;/plugin&gt;
 ...</pre></div>
 <p><i><a 
href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></section></section><section>
-<h3><a name="Lifecycle_Reference">Lifecycle Reference</a></h3>
+<h2><a name="Lifecycle_Reference">Lifecycle Reference</a></h2>
 <p>The following lists all build phases of the <code>default</code>, 
<code>clean</code> and <code>site</code> lifecycles, which are executed in the 
order given up to the point of the one specified.</p><section>
-<h4><a name="Clean_Lifecycle"></a>Clean Lifecycle</h4>
+<h3><a name="Clean_Lifecycle"></a>Clean Lifecycle</h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -298,7 +298,7 @@
 <tr class="b">
 <td align="left"><code>post-clean</code></td>
 <td align="left">execute processes needed to finalize the project 
cleaning</td></tr></table></section><section>
-<h4><a name="Default_Lifecycle"></a>Default Lifecycle</h4>
+<h3><a name="Default_Lifecycle"></a>Default Lifecycle</h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -372,7 +372,7 @@
 <tr class="b">
 <td align="left"><code>deploy</code></td>
 <td align="left">done in an integration or release environment, copies the 
final package to the remote repository for sharing with other developers and 
projects.</td></tr></table></section><section>
-<h4><a name="Site_Lifecycle"></a>Site Lifecycle</h4>
+<h3><a name="Site_Lifecycle"></a>Site Lifecycle</h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -390,9 +390,9 @@
 <td align="left"><code>site-deploy</code></td>
 <td align="left">deploy the generated site documentation to the specified web 
server</td></tr></table>
 <p><i><a 
href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></section></section><section>
-<h3><a name="Built-in_Lifecycle_Bindings">Built-in Lifecycle Bindings</a></h3>
+<h2><a name="Built-in_Lifecycle_Bindings">Built-in Lifecycle Bindings</a></h2>
 <p>Some phases have goals bound to them by default. And for the default 
lifecycle, these bindings depend on the packaging value. Here are some of the 
goal-to-build-phase bindings.</p><section>
-<h4><a name="Clean_Lifecycle_Bindings"></a>Clean Lifecycle Bindings</h4>
+<h3><a name="Clean_Lifecycle_Bindings"></a>Clean Lifecycle Bindings</h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -400,7 +400,7 @@
 <tr class="b">
 <td align="left"><code>clean</code></td>
 <td align="left"><code>clean:clean</code></td></tr></table></section><section>
-<h4><a 
name="Default_Lifecycle_Bindings_-_Packaging_ejb_.2F_ejb3_.2F_jar_.2F_par_.2F_rar_.2F_war"></a>Default
 Lifecycle Bindings - Packaging <code>ejb</code> / <code>ejb3</code> / 
<code>jar</code> / <code>par</code> / <code>rar</code> / <code>war</code></h4>
+<h3><a 
name="Default_Lifecycle_Bindings_-_Packaging_ejb_.2F_ejb3_.2F_jar_.2F_par_.2F_rar_.2F_war"></a>Default
 Lifecycle Bindings - Packaging <code>ejb</code> / <code>ejb3</code> / 
<code>jar</code> / <code>par</code> / <code>rar</code> / <code>war</code></h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -429,7 +429,7 @@
 <tr class="a">
 <td align="left"><code>deploy</code></td>
 <td 
align="left"><code>deploy:deploy</code></td></tr></table></section><section>
-<h4><a name="Default_Lifecycle_Bindings_-_Packaging_ear"></a>Default Lifecycle 
Bindings - Packaging <code>ear</code></h4>
+<h3><a name="Default_Lifecycle_Bindings_-_Packaging_ear"></a>Default Lifecycle 
Bindings - Packaging <code>ear</code></h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -449,7 +449,7 @@
 <tr class="b">
 <td align="left"><code>deploy</code></td>
 <td 
align="left"><code>deploy:deploy</code></td></tr></table></section><section>
-<h4><a name="Default_Lifecycle_Bindings_-_Packaging_maven-plugin"></a>Default 
Lifecycle Bindings - Packaging <code>maven-plugin</code></h4>
+<h3><a name="Default_Lifecycle_Bindings_-_Packaging_maven-plugin"></a>Default 
Lifecycle Bindings - Packaging <code>maven-plugin</code></h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -481,7 +481,7 @@
 <tr class="b">
 <td align="left"><code>deploy</code></td>
 <td 
align="left"><code>deploy:deploy</code></td></tr></table></section><section>
-<h4><a name="Default_Lifecycle_Bindings_-_Packaging_pom"></a>Default Lifecycle 
Bindings - Packaging <code>pom</code></h4>
+<h3><a name="Default_Lifecycle_Bindings_-_Packaging_pom"></a>Default Lifecycle 
Bindings - Packaging <code>pom</code></h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -495,7 +495,7 @@
 <tr class="b">
 <td align="left"><code>deploy</code></td>
 <td 
align="left"><code>deploy:deploy</code></td></tr></table></section><section>
-<h4><a name="Site_Lifecycle_Bindings"></a>Site Lifecycle Bindings</h4>
+<h3><a name="Site_Lifecycle_Bindings"></a>Site Lifecycle Bindings</h3>
 <table border="1" class="table table-striped">
 <tr class="a">
 <th align="left">Phase</th>
@@ -506,7 +506,7 @@
 <tr class="a">
 <td align="left"><code>site-deploy</code></td>
 <td align="left"><code>site:deploy</code></td></tr></table></section><section>
-<h4><a name="References"></a>References</h4>
+<h3><a name="References"></a>References</h3>
 <p>The full Maven lifecycle is defined by the <code>components.xml</code> file 
in the <code>maven-core</code> module, with <a 
href="/ref/current/maven-core/lifecycles.html">associated documentation</a> for 
reference.</p>
 <p>Default lifecycle bindings are defined in a separate <code><a 
class="externalLink" 
href="https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml";>default-bindings.xml</a></code>
 descriptor.</p>
 <p>See <a href="/ref/current/maven-core/lifecycles.html">Lifecycles 
Reference</a> and <a 
href="/ref/current/maven-core/default-bindings.html">Plugin Bindings for 
default Lifecycle Reference</a> for latest documentation taken directly from 
source code.</p>

Modified: maven/website/content/guides/introduction/introduction-to-the-pom.html
==============================================================================
--- maven/website/content/guides/introduction/introduction-to-the-pom.html 
(original)
+++ maven/website/content/guides/introduction/introduction-to-the-pom.html Sat 
Aug 20 12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/introduction/introduction-to-the-pom.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/introduction/introduction-to-the-pom.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Jason van Zyl
 Franz Allan Valencia See
 Brett Porter" />
@@ -148,7 +148,7 @@ Brett Porter" />
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Introduction_to_the_POM"></a>Introduction to the POM</h2>
+<h1><a name="Introduction_to_the_POM"></a>Introduction to the POM</h1>
 <ul>
 <li><a href="./introduction-to-the-pom.html#What_is_a_POM">What is a 
POM</a>?</li>
 <li><a href="./introduction-to-the-pom.html#Super_POM">Super POM</a></li>
@@ -167,15 +167,15 @@ Brett Porter" />
 <li><a href="./introduction-to-the-pom.html#Project_Interpolation">Project 
Interpolation and Variables</a>
 <ul>
 <li><a href="./introduction-to-the-pom.html#Available_Variables">Available 
Variables</a></li></ul></li></ul><section>
-<h3><a name="What_is_a_POM.3F"></a><a name="What_is_a_POM">What is a 
POM</a>?</h3>
+<h2><a name="What_is_a_POM.3F"></a><a name="What_is_a_POM">What is a 
POM</a>?</h2>
 <p>A Project Object Model or POM is the fundamental unit of work in Maven. It 
is an XML file that contains information about the project and configuration 
details used by Maven to build the project. It contains default values for most 
projects. Examples for this is the build directory, which is 
<code>target</code>; the source directory, which is <code>src/main/java</code>; 
the test source directory, which is <code>src/test/java</code>; and so on. When 
executing a task or goal, Maven looks for the POM in the current directory. It 
reads the POM, gets the needed configuration information, then executes the 
goal.</p>
 <p>Some of the configuration that can be specified in the POM are the project 
dependencies, the plugins or goals that can be executed, the build profiles, 
and so on. Other information such as the project version, description, 
developers, mailing lists and such can also be specified.</p>
 <p><a href="./introduction-to-the-pom.html">[top]</a></p></section><section>
-<h3><a name="Super_POM">Super POM</a></h3>
+<h2><a name="Super_POM">Super POM</a></h2>
 <p>The Super POM is Maven's default POM. All POMs extend the Super POM unless 
explicitly set, meaning the configuration specified in the Super POM is 
inherited by the POMs you created for your projects.</p>
 <p>You can see the <a 
href="/ref/3.6.3/maven-model-builder/super-pom.html">Super POM for Maven 
3.6.3</a> in Maven Core reference documentation.</p>
 <p><a href="./introduction-to-the-pom.html">[top]</a></p></section><section>
-<h3><a name="Minimal_POM">Minimal POM</a></h3>
+<h2><a name="Minimal_POM">Minimal POM</a></h2>
 <p>The minimum requirement for a POM are the following:</p>
 <ul>
 <li><code>project</code> root</li>
@@ -195,7 +195,7 @@ Brett Porter" />
 <p>Also, as mentioned in the <a href="#What_is_a_POM">first section</a>, if 
the configuration details are not specified, Maven will use their defaults. One 
of these default values is the packaging type. Every Maven project has a 
packaging type. If it is not specified in the POM, then the default value 
&quot;jar&quot; would be used.</p>
 <p>Furthermore, you can see that in the minimal POM the <i>repositories</i> 
were not specified. If you build your project using the minimal POM, it would 
inherit the <i>repositories</i> configuration in the Super POM. Therefore when 
Maven sees the dependencies in the minimal POM, it would know that these 
dependencies will be downloaded from 
<code>https://repo.maven.apache.org/maven2</code> which was specified in the 
Super POM.</p>
 <p><a href="./introduction-to-the-pom.html">[top]</a></p></section><section>
-<h3><a name="Project_Inheritance">Project Inheritance</a></h3>
+<h2><a name="Project_Inheritance">Project Inheritance</a></h2>
 <p>Elements in the POM that are merged are the following:</p>
 <ul>
 <li>dependencies</li>
@@ -205,8 +205,8 @@ Brett Porter" />
 <li>plugin configuration</li>
 <li>resources</li></ul>
 <p>The Super POM is one example of project inheritance, however you can also 
introduce your own parent POMs by specifying the parent element in the POM, as 
demonstrated in the following examples.</p><section>
-<h4><a name="Example_1">Example 1</a></h4><section>
-<h5><a name="The_Scenario"></a>The Scenario</h5>
+<h3><a name="Example_1">Example 1</a></h3><section>
+<h4><a name="The_Scenario"></a>The Scenario</h4>
 <p>As an example, let us reuse our previous artifact, 
com.mycompany.app:my-app:1. And let us introduce another artifact, 
com.mycompany.app:my-module:1.</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
   &lt;modelVersion&gt;4.0.0&lt;/modelVersion&gt;
@@ -222,7 +222,7 @@ Brett Porter" />
  |   `-- pom.xml
  `-- pom.xml</pre></div>
 <p><b>Note:</b> <code>my-module/pom.xml</code> is the POM of 
com.mycompany.app:my-module:1 while <code>pom.xml</code> is the POM of 
com.mycompany.app:my-app:1</p></section><section>
-<h5><a name="The_Solution"></a>The Solution</h5>
+<h4><a name="The_Solution"></a>The Solution</h4>
 <p>Now, if we were to turn com.mycompany.app:my-app:1 into a parent artifact 
of com.mycompany.app:my-module:1,we will have to modify 
com.mycompany.app:my-module:1's POM to the following configuration:</p>
 <p><b>com.mycompany.app:my-module:1's POM</b></p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
@@ -253,8 +253,8 @@ Brett Porter" />
 &lt;/project&gt;</pre></div>
 <p>This allows the module to inherit the groupId or the version of its parent 
POM.</p>
 <p><a 
href="./introduction-to-the-pom.html">[top]</a></p></section></section><section>
-<h4><a name="Example_2">Example 2</a></h4><section>
-<h5><a name="The_Scenario"></a>The Scenario</h5>
+<h3><a name="Example_2">Example 2</a></h3><section>
+<h4><a name="The_Scenario"></a>The Scenario</h4>
 <p>However, that would work if the parent project was already installed in our 
local repository or was in that specific directory structure (parent 
<code>pom.xml</code> is one directory higher than that of the module's 
<code>pom.xml</code>).</p>
 <p>But what if the parent is not yet installed and if the directory structure 
is as in the following example?</p>
 <div>
@@ -263,7 +263,7 @@ Brett Porter" />
  |   `-- pom.xml
  `-- parent
      `-- pom.xml</pre></div></section><section>
-<h5><a name="The_Solution"></a>The Solution</h5>
+<h4><a name="The_Solution"></a>The Solution</h4>
 <p>To address this directory structure (or any other directory structure), we 
would have to add the <code>&lt;relativePath&gt;</code> element to our parent 
section.</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
   &lt;modelVersion&gt;4.0.0&lt;/modelVersion&gt;
@@ -278,14 +278,14 @@ Brett Porter" />
   &lt;artifactId&gt;my-module&lt;/artifactId&gt;
 &lt;/project&gt;</pre></div>
 <p>As the name suggests, it's the relative path from the module's 
<code>pom.xml</code> to the parent's 
<code>pom.xml</code>.</p></section></section></section><section>
-<h3><a name="Project_Aggregation">Project Aggregation</a></h3>
+<h2><a name="Project_Aggregation">Project Aggregation</a></h2>
 <p>Project Aggregation is similar to <a href="#Project_Inheritance">Project 
Inheritance</a>. But instead of specifying the parent POM from the module, it 
specifies the modules from the parent POM. By doing so, the parent project now 
knows its modules, and if a Maven command is invoked against the parent 
project, that Maven command will then be executed to the parent's modules as 
well. To do Project Aggregation, you must do the following:</p>
 <ul>
 <li>Change the parent POMs packaging to the value &quot;pom&quot;.</li>
 <li>Specify in the parent POM the directories of its modules (children 
POMs).</li></ul>
 <p><a href="./introduction-to-the-pom.html">[top]</a></p><section>
-<h4><a name="Example_3">Example 3</a></h4><section>
-<h5><a name="The_Scenario"></a>The Scenario</h5>
+<h3><a name="Example_3">Example 3</a></h3><section>
+<h4><a name="The_Scenario"></a>The Scenario</h4>
 <p>Given the previous original artifact POMs and directory structure:</p>
 <p><b>com.mycompany.app:my-app:1's POM</b></p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
@@ -309,7 +309,7 @@ Brett Porter" />
  |-- my-module
  |   `-- pom.xml
  `-- pom.xml</pre></div></section><section>
-<h5><a name="The_Solution"></a>The Solution</h5>
+<h4><a name="The_Solution"></a>The Solution</h4>
 <p>If we are to aggregate my-module into my-app, we would only have to modify 
my-app.</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
   &lt;modelVersion&gt;4.0.0&lt;/modelVersion&gt;
@@ -326,8 +326,8 @@ Brett Porter" />
 <p>In the revised com.mycompany.app:my-app:1, the packaging section and the 
modules sections were added. For the packaging, its value was set to 
&quot;pom&quot;, and for the modules section, we have the element 
<code>&lt;module&gt;my-module&lt;/module&gt;</code>. The value of 
<code>&lt;module&gt;</code> is the relative path from the 
com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM (<i>by 
practice, we use the module's artifactId as the module directory's 
name</i>).</p>
 <p>Now, whenever a Maven command processes com.mycompany.app:my-app:1, that 
same Maven command would be ran against com.mycompany.app:my-module:1 as well. 
Furthermore, some commands (goals specifically) handle project aggregation 
differently.</p>
 <p><a 
href="./introduction-to-the-pom.html">[top]</a></p></section></section><section>
-<h4><a name="Example_4">Example 4</a></h4><section>
-<h5><a name="The_Scenario"></a>The Scenario</h5>
+<h3><a name="Example_4">Example 4</a></h3><section>
+<h4><a name="The_Scenario"></a>The Scenario</h4>
 <p>But what if we change the directory structure to the following:</p>
 <div>
 <pre>.
@@ -336,7 +336,7 @@ Brett Porter" />
  `-- parent
      `-- pom.xml</pre></div>
 <p>How would the parent POM specify its modules?</p></section><section>
-<h5><a name="The_Solution"></a>The Solution</h5>
+<h4><a name="The_Solution"></a>The Solution</h4>
 <p>The answer? - the same way as Example 3, by specifying the path to the 
module.</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
   &lt;modelVersion&gt;4.0.0&lt;/modelVersion&gt;
@@ -350,7 +350,7 @@ Brett Porter" />
     &lt;module&gt;../my-module&lt;/module&gt;
   &lt;/modules&gt;
 &lt;/project&gt;</pre></div></section></section></section><section>
-<h3><a name="Project_Inheritance_vs_Project_Aggregation">Project Inheritance 
vs Project Aggregation</a></h3>
+<h2><a name="Project_Inheritance_vs_Project_Aggregation">Project Inheritance 
vs Project Aggregation</a></h2>
 <p>If you have several Maven projects, and they all have similar 
configurations, you can refactor your projects by pulling out those similar 
configurations and making a parent project. Thus, all you have to do is to let 
your Maven projects inherit that parent project, and those configurations would 
then be applied to all of them.</p>
 <p>And if you have a group of projects that are built or processed together, 
you can create a parent project and have that parent project declare those 
projects as its modules. By doing so, you'd only have to build the parent and 
the rest will follow.</p>
 <p>But of course, you can have both Project Inheritance and Project 
Aggregation. Meaning, you can have your modules specify a parent project, and 
at the same time, have that parent project specify those Maven projects as its 
modules. You'd just have to apply all three rules:</p>
@@ -359,8 +359,8 @@ Brett Porter" />
 <li>Change the parent POMs packaging to the value &quot;pom&quot; .</li>
 <li>Specify in the parent POM the directories of its modules (children 
POMs)</li></ul>
 <p><a href="./introduction-to-the-pom.html">[top]</a></p><section>
-<h4><a name="Example_5">Example 5</a></h4><section>
-<h5><a name="The_Scenario"></a>The Scenario</h5>
+<h3><a name="Example_5">Example 5</a></h3><section>
+<h4><a name="The_Scenario"></a>The Scenario</h4>
 <p>Given the previous original artifact POMs again,</p>
 <p><b>com.mycompany.app:my-app:1's POM</b></p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
@@ -385,7 +385,7 @@ Brett Porter" />
  |   `-- pom.xml
  `-- parent
      `-- pom.xml</pre></div></section><section>
-<h5><a name="The_Solution"></a>The Solution</h5>
+<h4><a name="The_Solution"></a>The Solution</h4>
 <p>To do both project inheritance and aggregation, you only have to apply all 
three rules.</p>
 <p><b>com.mycompany.app:my-app:1's POM</b></p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
@@ -415,16 +415,16 @@ Brett Porter" />
 &lt;/project&gt;</pre></div>
 <p><b>NOTE:</b> Profile inheritance the same inheritance strategy as used for 
the POM itself.</p>
 <p><a 
href="./introduction-to-the-pom.html">[top]</a></p></section></section></section><section>
-<h3><a name="Project_Interpolation_and_Variables"></a><a 
name="Project_Interpolation">Project Interpolation</a> and Variables</h3>
+<h2><a name="Project_Interpolation_and_Variables"></a><a 
name="Project_Interpolation">Project Interpolation</a> and Variables</h2>
 <p>One of the practices that Maven encourages is <i>don't repeat yourself</i>. 
However, there are circumstances where you will need to use the same value in 
several different locations. To assist in ensuring the value is only specified 
once, Maven allows you to use both your own and pre-defined variables in the 
POM.</p>
 <p>For example, to access the <code>project.version</code> variable, you would 
reference it like so:</p>
 <div class="source"><pre class="prettyprint linenums">  
&lt;version&gt;${project.version}&lt;/version&gt;</pre></div>
 <p>One factor to note is that these variables are processed <i>after</i> 
inheritance as outlined above. This means that if a parent project uses a 
variable, then its definition in the child, not the parent, will be the one 
eventually used.</p><section>
-<h4><a name="Available_Variables">Available Variables</a></h4><section>
-<h5><a name="Project_Model_Variables"></a>Project Model Variables</h5>
+<h3><a name="Available_Variables">Available Variables</a></h3><section>
+<h4><a name="Project_Model_Variables"></a>Project Model Variables</h4>
 <p>Any field of the model that is a single value element can be referenced as 
a variable. For example, <code>${project.groupId}</code>, 
<code>${project.version}</code>, <code>${project.build.sourceDirectory}</code> 
and so on. Refer to the POM reference to see a full list of properties.</p>
 <p>These variables are all referenced by the prefix 
&quot;<code>project.</code>&quot;. You may also see references with 
<code>pom.</code> as the prefix, or the prefix omitted entirely - these forms 
are now deprecated and should not be used.</p></section><section>
-<h5><a name="Special_Variables"></a>Special Variables</h5>
+<h4><a name="Special_Variables"></a>Special Variables</h4>
 <table border="1" class="table table-striped">
 <tr class="a">
 <td align="left"><code>project.basedir</code></td>
@@ -444,7 +444,7 @@ Brett Porter" />
   ...
 &lt;/project&gt;</pre></div>
 <p>The format pattern has to comply with the rules given in the API 
documentation for <a class="externalLink" 
href="https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html";>SimpleDateFormat</a>.
 If the property is not present, the format defaults to the value already given 
in the example.</p></section><section>
-<h5><a name="Properties"></a>Properties</h5>
+<h4><a name="Properties"></a>Properties</h4>
 <p>You are also able to reference any properties defined in the project as a 
variable. Consider the following example:</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
   ...

Modified: 
maven/website/content/guides/introduction/introduction-to-the-standard-directory-layout.html
==============================================================================
--- 
maven/website/content/guides/introduction/introduction-to-the-standard-directory-layout.html
 (original)
+++ 
maven/website/content/guides/introduction/introduction-to-the-standard-directory-layout.html
 Sat Aug 20 12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/introduction/introduction-to-the-standard-directory-layout.apt
 at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/introduction/introduction-to-the-standard-directory-layout.apt
 at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Jason van Zyl" />
     <meta name="date" content="2014-03-09" />
     <title>Maven &#x2013; Introduction to the Standard Directory Layout</title>
@@ -146,7 +146,7 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Introduction_to_the_Standard_Directory_Layout"></a>Introduction 
to the Standard Directory Layout</h2>
+<h1><a name="Introduction_to_the_Standard_Directory_Layout"></a>Introduction 
to the Standard Directory Layout</h1>
 <p>Having a common directory layout allows users familiar with one Maven 
project to immediately feel at home in another Maven project. The advantages 
are analogous to adopting a site-wide look-and-feel.</p>
 <p>The next section documents the directory layout expected by Maven and the 
directory layout created by Maven. Try to conform to this structure as much as 
possible. However, if you can't, these settings can be overridden via the 
project descriptor.</p>
 <table border="1" class="table table-striped">

Modified: maven/website/content/guides/mini/guide-3rd-party-jars-local.html
==============================================================================
--- maven/website/content/guides/mini/guide-3rd-party-jars-local.html (original)
+++ maven/website/content/guides/mini/guide-3rd-party-jars-local.html Sat Aug 
20 12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-3rd-party-jars-local.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-3rd-party-jars-local.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Jason van Zyl
 Robert Scholte" />
     <meta name="date" content="2013-07-13" />
@@ -154,7 +154,7 @@ Robert Scholte" />
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Guide_to_installing_3rd_party_JARs"></a>Guide to installing 3rd 
party JARs</h2>
+<h1><a name="Guide_to_installing_3rd_party_JARs"></a>Guide to installing 3rd 
party JARs</h1>
 <p>Occasionally, you will have 3rd party JARs that you need to put in your 
local repository for use in your builds, since they don't exist in any public 
repository like <a class="externalLink" href="https://search.maven.org";>Maven 
Central</a>. The JARs must be placed in the local repository in the correct 
place in order for it to be correctly picked up by Apache Maven.</p>
 <p>To make this easier, and less error prone, we have provided an 
<code>install-file</code> goal in the <a 
href="/plugins/maven-install-plugin/">maven-install-plugin</a> which should 
make this relatively painless. </p>
 <p>To install a JAR in the local repository use the following command:</p>

Modified: maven/website/content/guides/mini/guide-3rd-party-jars-remote.html
==============================================================================
--- maven/website/content/guides/mini/guide-3rd-party-jars-remote.html 
(original)
+++ maven/website/content/guides/mini/guide-3rd-party-jars-remote.html Sat Aug 
20 12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-3rd-party-jars-remote.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-3rd-party-jars-remote.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Allan Ramirez" />
     <meta name="date" content="2006-02-22" />
     <title>Maven &#x2013; Guide to deploying 3rd party JARs to remote 
repository</title>
@@ -153,7 +153,7 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Guide_to_deploying_3rd_party_JARs_to_remote_repository"></a>Guide 
to deploying 3rd party JARs to remote repository</h2>
+<h1><a name="Guide_to_deploying_3rd_party_JARs_to_remote_repository"></a>Guide 
to deploying 3rd party JARs to remote repository</h1>
 <p>Same concept of the <a 
href="./guide-3rd-party-jars-local.html">install:install-file</a> goal of the 
maven-install-plugin where the 3rd party JAR is installed in the local 
repository. But this time instead to local repository the JAR will be install 
both in the local and remote repository.</p>
 <p>To deploy a 3rd party JAR use the deploy:deploy-file goal under 
maven-deploy-plugin.</p>
 <p>First, the wagon-provider(wagon-ftp, wagon-file, etc..) must be placed to 
your <code>${maven.home}/lib</code>.</p>
@@ -165,17 +165,17 @@
   -Dfile=&lt;path-to-file&gt; \
   -DrepositoryId=&lt;id-to-map-on-server-section-of-settings.xml&gt; \
   -Durl=&lt;url-of-the-repository-to-deploy&gt;</pre></div><section>
-<h3><a name="Deploying_a_3rd_party_JAR_with_a_generic_POM"></a>Deploying a 3rd 
party JAR with a generic POM</h3>
+<h2><a name="Deploying_a_3rd_party_JAR_with_a_generic_POM"></a>Deploying a 3rd 
party JAR with a generic POM</h2>
 <p>By default, deploy:deploy-file generates a generic POM(.pom) to be deploy 
together with the 3rd party JAR. To disable this feature we should set the 
<code>generatePOM</code> argument to false.</p>
 <div class="source"><pre class="prettyprint 
linenums">-DgeneratePom=false</pre></div></section><section>
-<h3><a name="Deploying_a_3rd_party_JAR_with_a_customized_POM"></a>Deploying a 
3rd party JAR with a customized POM</h3>
+<h2><a name="Deploying_a_3rd_party_JAR_with_a_customized_POM"></a>Deploying a 
3rd party JAR with a customized POM</h2>
 <p>If a POM is already existing for the 3rd Party JAR and you want to deploy 
it together with the JAR we should use the <code>pomFile</code> argument of the 
deploy-file goal. See sample below.</p>
 <div class="source"><pre class="prettyprint linenums">mvn deploy:deploy-file 
-DpomFile=&lt;path-to-pom&gt; \
   -Dfile=&lt;path-to-file&gt; \
   -DrepositoryId=&lt;id-to-map-on-server-section-of-settings.xml&gt; \
   -Durl=&lt;url-of-the-repository-to-deploy&gt;</pre></div>
 <p>Note that <code>groupId</code>, <code>artifactId</code>, 
<code>version</code> and <code>packaging</code> arguments are not included here 
because deploy-file goal will get these information from the given 
POM.</p></section><section>
-<h3><a name="Deploying_Source_Jars"></a>Deploying Source Jars</h3>
+<h2><a name="Deploying_Source_Jars"></a>Deploying Source Jars</h2>
 <p>To deploy a 3rd party source jar, packaging should be set to 
<code>java-source</code>, and generatePom should be set to 
<code>false</code>.</p></section></section>
         </main>
       </div>

Modified: maven/website/content/guides/mini/guide-archive-configuration.html
==============================================================================
--- maven/website/content/guides/mini/guide-archive-configuration.html 
(original)
+++ maven/website/content/guides/mini/guide-archive-configuration.html Sat Aug 
20 12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-archive-configuration.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-archive-configuration.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Brett Porter" />
     <meta name="date" content="2006-06-21" />
     <title>Maven &#x2013; Guide to Configuring Archive Plugins</title>
@@ -155,9 +155,9 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Guide_to_Configuring_Archive_Plugins"></a>Guide to Configuring 
Archive Plugins</h2>
+<h1><a name="Guide_to_Configuring_Archive_Plugins"></a>Guide to Configuring 
Archive Plugins</h1>
 <p>Many Java archive generating plugins accept the <code>archive</code> 
configuration element to customize the generation of the archive. In the 
standard Maven Plugins, this includes the <code>jar</code>, <code>war</code>, 
<code>ejb</code>, <code>ear</code> and <code>assembly</code> 
plugins.</p><section>
-<h3><a name="Disabling_Maven_Meta_Information"></a>Disabling Maven Meta 
Information</h3>
+<h2><a name="Disabling_Maven_Meta_Information"></a>Disabling Maven Meta 
Information</h2>
 <p>By default, Maven generated archives include the 
<code>META-INF/maven</code> directory, which contains the <code>pom.xml</code> 
file used to build the archive, and a <code>pom.properties</code> file that 
includes some basic properties in a small, easier to read format.</p>
 <p>To disable the generation of these files, include the following 
configuration for your plugin (in this example, the WAR plugin is used):</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
@@ -179,7 +179,7 @@
   ...
 &lt;/project&gt;
 </pre></div></section><section>
-<h3><a name="Configuring_the_Manifest"></a>Configuring the Manifest</h3>
+<h2><a name="Configuring_the_Manifest"></a>Configuring the Manifest</h2>
 <p>The archive configuration also accepts manifest configuration. See <a 
href="./guide-manifest.html">Guide to Working with Manifests</a> for more 
information.</p></section></section>
         </main>
       </div>

Modified: maven/website/content/guides/mini/guide-assemblies.html
==============================================================================
--- maven/website/content/guides/mini/guide-assemblies.html (original)
+++ maven/website/content/guides/mini/guide-assemblies.html Sat Aug 20 12:41:42 
2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-assemblies.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-assemblies.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Jason van Zyl" />
     <meta name="date" content="2005-10-12" />
     <title>Maven &#x2013; Guide to Creating Assemblies</title>
@@ -155,7 +155,7 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Guide_to_creating_assemblies"></a>Guide to creating 
assemblies</h2>
+<h1><a name="Guide_to_creating_assemblies"></a>Guide to creating 
assemblies</h1>
 <p>The assembly mechanism in Maven provides an easy way to create 
distributions using a assembly descriptor and dependency information found in 
you POM. In order to use the assembly plug-in you need to configure the 
assembly plug-in in your POM and it might look like the following:</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
   &lt;parent&gt;
@@ -193,7 +193,7 @@
   ...
 &lt;/project&gt;</pre></div>
 <p>You'll notice that the assembly descriptor is located in 
<code>${project.basedir}/src/assembly</code> which is the <a 
href="../introduction/introduction-to-the-standard-directory-layout.html">standard</a>
 location for assembly descriptors.</p><section>
-<h3><a name="Creating_a_binary_assembly"></a>Creating a binary assembly</h3>
+<h2><a name="Creating_a_binary_assembly"></a>Creating a binary assembly</h2>
 <p>This is the most typical usage of the assembly plugin where you are 
creating a distribution for standard use.</p>
 <div class="source"><pre class="prettyprint linenums">&lt;assembly 
xmlns=&quot;http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2&quot;
 xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;
   
xsi:schemaLocation=&quot;http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
 http://maven.apache.org/xsd/assembly-1.1.2.xsd&quot;&gt;

Modified: maven/website/content/guides/mini/guide-attached-tests.html
==============================================================================
--- maven/website/content/guides/mini/guide-attached-tests.html (original)
+++ maven/website/content/guides/mini/guide-attached-tests.html Sat Aug 20 
12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-attached-tests.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-attached-tests.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Jason van Zyl" />
     <meta name="date" content="2005-10-12" />
     <title>Maven &#x2013; Guide to using attached tests</title>
@@ -124,7 +124,7 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Guide_to_using_attached_tests"></a>Guide to using attached 
tests</h2>
+<h1><a name="Guide_to_using_attached_tests"></a>Guide to using attached 
tests</h1>
 <p>Many times you may want to reuse the tests that you have created for a 
project in another. For example if you have written <code>foo-core</code> and 
it contains test code in the <code>${basedir}/src/test/java</code> it would be 
useful to package up those compiled tests in a JAR and deploy them for general 
reuse. To do this you would configure the <code>maven-jar-plugin</code> as 
follows:</p>
 <div class="source"><pre class="prettyprint linenums">
 &lt;project&gt;
@@ -146,17 +146,17 @@
   &lt;/build&gt;
 &lt;/project&gt;
 </pre></div><section>
-<h3><a name="Installing_the_attached_test_JAR"></a>Installing the attached 
test JAR</h3>
+<h2><a name="Installing_the_attached_test_JAR"></a>Installing the attached 
test JAR</h2>
 <p>In order to install the attached test JAR you simply use the standard 
<code>install</code> phase by executing the following command:</p>
 <div class="source"><pre class="prettyprint linenums">
 mvn install
 </pre></div></section><section>
-<h3><a name="Deploying_the_attached_test_JAR"></a>Deploying the attached test 
JAR</h3>
+<h2><a name="Deploying_the_attached_test_JAR"></a>Deploying the attached test 
JAR</h2>
 <p>In order to deploy the attached test JAR you simply use the standard 
<code>deploy</code> phase by executing the following command:</p>
 <div class="source"><pre class="prettyprint linenums">
 mvn deploy
 </pre></div></section><section>
-<h3><a name="Using_the_attached_test_JAR"></a>Using the attached test JAR</h3>
+<h2><a name="Using_the_attached_test_JAR"></a>Using the attached test JAR</h2>
 <p>In order to use the attached test JAR that was created above you simply 
specify a dependency on the main artifact with a specified type of 
<code>test-jar</code> and the <code>classifier</code>.</p>
 <div class="source"><pre class="prettyprint linenums">
 &lt;project&gt;

Modified: maven/website/content/guides/mini/guide-bash-m2-completion.html
==============================================================================
--- maven/website/content/guides/mini/guide-bash-m2-completion.html (original)
+++ maven/website/content/guides/mini/guide-bash-m2-completion.html Sat Aug 20 
12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-bash-m2-completion.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-bash-m2-completion.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Trygve Laugstol
 Jason van Zyl
 Karl Heinz Marbaise" />
@@ -126,7 +126,7 @@ Karl Heinz Marbaise" />
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Guide_to_Maven_auto_completion_using_BASH"></a>Guide to Maven 
auto completion using BASH</h2>
+<h1><a name="Guide_to_Maven_auto_completion_using_BASH"></a>Guide to Maven 
auto completion using BASH</h1>
 <p>If you like having bash completion which i can recommend if you are working 
with Maven on command line i would suggest to install the following <a 
class="externalLink" 
href="https://github.com/juven/maven-bash-completion";>Maven Bash Auto 
Completion</a> to fullfil you needs.</p></section>
         </main>
       </div>

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
 Sat Aug 20 12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-building-for-different-environments.apt at 
2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-building-for-different-environments.apt at 
2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Trygve Laugstøl" />
     <meta name="date" content="2006-01-01" />
     <title>Maven &#x2013; Building For Different Environments</title>
@@ -155,7 +155,7 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Building_For_Different_Environments"></a>Building For Different 
Environments</h2>
+<h1><a name="Building_For_Different_Environments"></a>Building For Different 
Environments</h1>
 <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>
 <ul>
@@ -232,13 +232,13 @@ src/
 <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 &quot;attached&quot; JAR with 
the &quot;test&quot; classifier.
 <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, &quot;foo-1.0.jar&quot; and 
&quot;foo-1.0-test.jar&quot;. These two jars will identical. 
</p></li></ol></li></ul></section><section>
-<h2><a name="Caveats"></a>Caveats</h2>
+<h1><a name="Caveats"></a>Caveats</h1>
 <ul>
 <li>Currently Maven doesn't allow a project build to only produce attached 
artifacts. (i.e. it has to produce a &quot;main&quot; 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 &quot;mvn clean&quot; 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>
+<h1><a name="Resources"></a>Resources</h1>
 <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></section>

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 Sat Aug 20 
12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-configuring-maven.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-configuring-maven.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Brett Porter" />
     <meta name="date" content="2005-04-12" />
     <title>Maven &#x2013; Guide to Configuring Maven</title>
@@ -155,7 +155,7 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Configuring_Maven"></a>Configuring Maven</h2>
+<h1><a name="Configuring_Maven"></a>Configuring Maven</h1>
 <p>Maven configuration occurs at 3 levels:</p>
 <ul>
 <li><i>Project</i> - most static configuration occurs in 
<code>pom.xml</code></li>
@@ -165,7 +165,7 @@
 <p><b>Note:</b> the installation and user configuration cannot be used to add 
shared project information - for example, setting 
<code>&lt;organization&gt;</code> or 
<code>&lt;distributionManagement&gt;</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>
+<h2><a name="Configuring_your_Local_Repository"></a>Configuring your Local 
Repository</h2>
 <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 class="source"><pre class="prettyprint linenums">&lt;settings&gt;
   ...
@@ -173,17 +173,17 @@
   ...
 &lt;/settings&gt;</pre></div>
 <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>
+<h2><a name="Configuring_a_Proxy"></a>Configuring a Proxy</h2>
 <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></section><section>
-<h3><a name="Configuring_Parallel_Artifact_Resolution"></a>Configuring 
Parallel Artifact Resolution</h3>
+<h2><a name="Configuring_Parallel_Artifact_Resolution"></a>Configuring 
Parallel Artifact Resolution</h2>
 <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 
<code>MAVEN_OPTS</code> environment variable. For example:</p>
 <div>
 <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>
+<h2><a name="Security_and_Deployment_Settings"></a>Security and Deployment 
Settings</h2>
 <p>Repositories to deploy to are defined in a project in the 
<code>&lt;distributionManagement&gt;</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>
@@ -204,13 +204,13 @@
   ...
 &lt;/settings&gt;</pre></div>
 <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>
+<h2><a name="Using_Mirrors_for_Repositories"></a>Using Mirrors for 
Repositories</h2>
 <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>
+<h2><a name="Profiles"></a>Profiles</h2>
 <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>
+<h2><a name="Optional_configuration"></a>Optional configuration</h2>
 <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>
+<h3><a name="Settings"></a>Settings</h3>
 <p>Maven has a settings file located in the Maven installation and/or user 
home directory that configure environmental specifics such as:</p>
 <ul>
 <li>HTTP proxy server</li>
@@ -218,9 +218,9 @@
 <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></section><section>
-<h4><a name="Security"></a>Security</h4>
+<h3><a name="Security"></a>Security</h3>
 <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>
+<h3><a name="Toolchains"></a>Toolchains</h3>
 <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>
         </main>
       </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 Sat Aug 20 
12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-configuring-plugins.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-configuring-plugins.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Jason van Zyl
 Vincent Siveton" />
     <meta name="date" content="2009-08-26" />
@@ -143,7 +143,7 @@ Vincent Siveton" />
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Guide_to_Configuring_Plug-ins"></a>Guide to Configuring 
Plug-ins</h2>
+<h1><a name="Guide_to_Configuring_Plug-ins"></a>Guide to Configuring 
Plug-ins</h1>
 <ol style="list-style-type: decimal">
 <li><a href="#Generic_Configuration">Generic Configuration</a>
 <ol style="list-style-type: decimal">
@@ -167,14 +167,14 @@ Vincent Siveton" />
 <li><a href="#Using_the_reporting_Tag_VS_build_Tag">Using the 
<code>&lt;reporting&gt;</code> Tag VS <code>&lt;build&gt;</code> Tag</a></li>
 <li><a href="#Using_the_reportSets_Tag">Using the 
<code>&lt;reportSets&gt;</code> Tag</a></li>
 <li><a href="#Using_the_inherited_Tag_In_Reporting_Plugins">Using the 
<code>&lt;inherited&gt;</code> Tag In Reporting 
Plugins</a></li></ol></li></ol><section>
-<h3><a name="Introduction"></a>Introduction</h3>
+<h2><a name="Introduction"></a>Introduction</h2>
 <p>In Maven, there are two kinds of plugins, build and reporting:</p>
 <ul>
 <li><b>Build plugins</b> are executed during the build and configured in the 
<code>&lt;build/&gt;</code> element.</li>
 <li><b>Reporting plugins</b> are executed during the site generation and 
configured in the <code>&lt;reporting/&gt;</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>: Always define the version of each plugin used to 
guarantee build reproducibility. A good practice is to specify each build 
plugin's version in a 
<code>&lt;build&gt;&lt;pluginManagement/&gt;&lt;/build&gt;</code> element. 
Often the &lt;pluginManagement/&gt; element is found in the parent POM. For 
reporting plugins, specify each version in the 
<code>&lt;reporting&gt;&lt;plugins/&gt;&lt;/reporting&gt;</code> element (and 
in the <code>&lt;build&gt;&lt;pluginManagement/&gt;&lt;/build&gt;</code> 
element too).</p></section><section>
-<h3><a name="Generic_Configuration">Generic Configuration</a></h3>
+<h2><a name="Generic_Configuration">Generic Configuration</a></h2>
 <p>Maven plugins (build and reporting) are configured by specifying a 
<code>&lt;configuration&gt;</code> element where the child elements of the 
<code>&lt;configuration&gt;</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, you have a Mojo that performs 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">@Mojo( name = 
&quot;query&quot; )
 public class MyQueryMojo
@@ -222,13 +222,13 @@ public class MyQueryMojo
 <div>
 <pre>mvn myquery:query -Dquery.url=http://maven.apache.org</pre></div>
 <p>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>
+<h3><a name="Help_Goal">Help Goal</a></h3>
 <p>Most Maven plugins have a <code>help</code> goal that prints a description 
of the plugin and its parameters and types. For instance, to see help for the 
javadoc goal, type:</p>
 <div>
 <pre>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></section><section>
-<h4><a name="Configuring_Parameters">Configuring Parameters</a></h4><section>
-<h5><a name="Mapping_Simple_Objects">Mapping Simple Objects</a></h5>
+<h3><a name="Configuring_Parameters">Configuring Parameters</a></h3><section>
+<h4><a name="Mapping_Simple_Objects">Mapping Simple Objects</a></h4>
 <p>Mapping simple types, like Boolean or Integer, is very simple. The 
<code>&lt;configuration&gt;</code> element might look like the following:</p>
 <div class="source"><pre class="prettyprint linenums">...
 &lt;configuration&gt;
@@ -240,7 +240,7 @@ public class MyQueryMojo
   &lt;myURL&gt;http://maven.apache.org&lt;/myURL&gt;
 &lt;/configuration&gt;
 ...</pre></div></section><section>
-<h5><a name="Mapping_Complex_Objects">Mapping Complex Objects</a></h5>
+<h4><a name="Mapping_Complex_Objects">Mapping Complex Objects</a></h4>
 <p>Mapping complex types is also fairly straight forward. Let's look at a 
simple example where we are trying to map a configuration for Person object. 
The <code>&lt;configuration/&gt;</code> element might look like the 
following:</p>
 <div class="source"><pre class="prettyprint linenums">...
 &lt;configuration&gt;
@@ -263,9 +263,9 @@ public class MyQueryMojo
   &lt;/person&gt;
 &lt;/configuration&gt;
 ...</pre></div></section><section>
-<h5><a name="Mapping_Collections">Mapping Collections</a></h5>
+<h4><a name="Mapping_Collections">Mapping Collections</a></h4>
 <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>
+<h5><a name="Mapping_Lists">Mapping Lists</a></h5>
 <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
     extends AbstractMojo
@@ -305,7 +305,7 @@ public class MyQueryMojo
 <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 <code>String</code>. 
Otherwise, the configuration will fail.</li></ol></section><section>
-<h6><a name="Mapping_Maps">Mapping Maps</a></h6>
+<h5><a name="Mapping_Maps">Mapping Maps</a></h5>
 <p>In the same way, you could define maps like the following:</p>
 <div class="source"><pre class="prettyprint linenums">...
     @Parameter(property = &quot;myMap&quot;)
@@ -319,7 +319,7 @@ public class MyQueryMojo
     &lt;/myMap&gt;
   &lt;/configuration&gt;
 ...</pre></div></section><section>
-<h6><a name="Mapping_Properties">Mapping Properties</a></h6>
+<h5><a name="Mapping_Properties">Mapping Properties</a></h5>
 <p>Properties should be defined like the following:</p>
 <div class="source"><pre class="prettyprint linenums">...
     @Parameter(property = &quot;myProperties&quot;)
@@ -339,9 +339,9 @@ public class MyQueryMojo
     &lt;/myProperties&gt;
   &lt;/configuration&gt;
 ...</pre></div></section></section></section></section><section>
-<h3><a name="Configuring_Build_Plugins">Configuring Build Plugins</a></h3>
+<h2><a name="Configuring_Build_Plugins">Configuring Build Plugins</a></h2>
 <p>The following is only to configure Build plugins in the 
<code>&lt;build&gt;</code> element.</p><section>
-<h4><a name="Using_the_.3Cexecutions.3E_Tag"></a><a 
name="Using_the_executions_Tag">Using the <code>&lt;executions&gt;</code> 
Tag</a></h4>
+<h3><a name="Using_the_.3Cexecutions.3E_Tag"></a><a 
name="Using_the_executions_Tag">Using the <code>&lt;executions&gt;</code> 
Tag</a></h3>
 <p>You can also configure a mojo using the <code>&lt;executions&gt;</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">&lt;project&gt;
   ...
@@ -481,7 +481,7 @@ public class MyBoundQueryMojo
 <p><b>Note:</b> Configurations inside the <code>&lt;executions&gt;</code> 
element used to differ from those that are outside 
<code>&lt;executions&gt;</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>
 <pre>mvn myquery:query@execution1</pre></div></section><section>
-<h4><a name="Using_the_.3Cdependencies.3E_Tag"></a><a 
name="Using_the_dependencies_Tag">Using the <code>&lt;dependencies&gt;</code> 
Tag</a></h4>
+<h3><a name="Using_the_.3Cdependencies.3E_Tag"></a><a 
name="Using_the_dependencies_Tag">Using the <code>&lt;dependencies&gt;</code> 
Tag</a></h3>
 <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 <code>&lt;dependencies&gt;</code> element like the following:</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
@@ -510,7 +510,7 @@ public class MyBoundQueryMojo
   &lt;/build&gt;
   ...
 &lt;/project&gt;</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>&lt;inherited&gt;</code> Tag In Build Plugins</a></h4>
+<h3><a name="Using_the_.3Cinherited.3E_Tag_In_Build_Plugins"></a><a 
name="Using_the_inherited_Tag_In_Build_Plugins">Using the 
<code>&lt;inherited&gt;</code> Tag In Build Plugins</a></h3>
 <p>By default, plugin configuration should be propagated to child POMs, so to 
break the inheritance, you could use the <code>&lt;inherited&gt;</code> tag:</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
   ...
@@ -527,16 +527,16 @@ public class MyBoundQueryMojo
   &lt;/build&gt;
   ...
 &lt;/project&gt;</pre></div></section></section><section>
-<h3><a name="Configuring_Reporting_Plugins">Configuring Reporting 
Plugins</a></h3>
+<h2><a name="Configuring_Reporting_Plugins">Configuring Reporting 
Plugins</a></h2>
 <p>The following is only to configure Reporting plugins in the 
<code>&lt;reporting&gt;</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>&lt;reporting&gt;</code> Tag VS <code>&lt;build&gt;</code> Tag</a></h4>
+<h3><a name="Using_the_.3Creporting.3E_Tag_VS_.3Cbuild.3E_Tag"></a><a 
name="Using_the_reporting_Tag_VS_build_Tag">Using the 
<code>&lt;reporting&gt;</code> Tag VS <code>&lt;build&gt;</code> Tag</a></h3>
 <p>Configuring a reporting plugin in the <code>&lt;reporting&gt;</code> or 
<code>&lt;build&gt;</code> elements in the pom does not exactly have the same 
results.</p>
 <dl>
 <dt><code>mvn site</code></dt>
 <dd>Since maven-site-plugin 3.4, it uses the parameters defined in the 
<code>&lt;configuration&gt;</code> element of each reporting Plugin specified 
in the <code>&lt;reporting&gt;</code> element, in addition to the parameters 
defined in the <code>&lt;configuration&gt;</code> element of each plugin 
specified in <code>&lt;build&gt;</code> (parameters from 
<code>&lt;build&gt;</code> section were previously ignored).</dd>
 <dt><code>mvn aplugin:areportgoal</code></dt>
 <dd>It <b>ignores</b> the parameters defined in the 
<code>&lt;configuration&gt;</code> element of each reporting Plugin specified 
in the <code>&lt;reporting&gt;</code> element; only parameters defined in the 
<code>&lt;configuration&gt;</code> element of each plugin specified in 
<code>&lt;build&gt;</code> are used.</dd></dl></section><section>
-<h4><a name="Using_the_.3CreportSets.3E_Tag"></a><a 
name="Using_the_reportSets_Tag">Using the <code>&lt;reportSets&gt;</code> 
Tag</a></h4>
+<h3><a name="Using_the_.3CreportSets.3E_Tag"></a><a 
name="Using_the_reportSets_Tag">Using the <code>&lt;reportSets&gt;</code> 
Tag</a></h3>
 <p>You can configure a reporting plugin using the 
<code>&lt;reportSets&gt;</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">&lt;project&gt;
   ...
@@ -567,7 +567,7 @@ public class MyBoundQueryMojo
     &lt;/reportSet&gt;
   &lt;/reportSets&gt;</pre></div></li>
 <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>&lt;inherited&gt;</code> Tag In Reporting Plugins</a></h4>
+<h3><a name="Using_the_.3Cinherited.3E_Tag_In_Reporting_Plugins"></a><a 
name="Using_the_inherited_Tag_In_Reporting_Plugins">Using the 
<code>&lt;inherited&gt;</code> Tag In Reporting Plugins</a></h3>
 <p>Similar to the build plugins, to break the inheritance, you can use the 
<code>&lt;inherited&gt;</code> tag:</p>
 <div class="source"><pre class="prettyprint linenums">&lt;project&gt;
   ...

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 Sat Aug 20 
12:41:42 2022
@@ -2,14 +2,14 @@
 
 
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.11.1 from 
content/apt/guides/mini/guide-creating-archetypes.apt at 2022-08-20
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from 
content/apt/guides/mini/guide-creating-archetypes.apt at 2022-08-20
  | Rendered using Apache Maven Fluido Skin 1.11.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml"; lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" />
+    <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" 
/>
     <meta name="author" content="Jason van Zyl, Alexander Hars, Franz Allan 
Valencia See" />
     <meta name="date" content="2010-04-10" />
     <title>Maven &#x2013; Guide to Creating Archetypes</title>
@@ -141,7 +141,7 @@
         </header>
         <main id="bodyColumn"  class="span10" >
 <section>
-<h2><a name="Guide_to_Creating_Archetypes"></a>Guide to Creating 
Archetypes</h2>
+<h1><a name="Guide_to_Creating_Archetypes"></a>Guide to Creating 
Archetypes</h1>
 <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> (<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>
@@ -149,7 +149,7 @@
 <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>
+<h2><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</h2>
 <p>An example <code>pom.xml</code> for an archetype artifact looks as 
follows:</p>
 <div class="source"><pre class="prettyprint linenums">
 &lt;project xmlns=&quot;http://maven.apache.org/POM/4.0.0&quot; 
xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;
@@ -173,7 +173,7 @@
 &lt;/project&gt;
 </pre></div>
 <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>
+<h2><a name="a2._Create_the_archetype_descriptor"></a>2. Create the archetype 
descriptor</h2>
 <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">
 &lt;archetype-descriptor
@@ -219,7 +219,7 @@ archetype
                         `-- java
                             `-- AppTest.java
 </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>
+<h2><a name="a3._Create_the_prototype_files_and_the_prototype_pom.xml"></a>3. 
Create the prototype files and the prototype pom.xml</h2>
 <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">
@@ -245,7 +245,7 @@ archetype
     &lt;/dependencies&gt;
 &lt;/project&gt;
 </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>
+<h2><a name="a4._Install_the_archetype_and_run_the_archetype_plugin"></a>4. 
Install the archetype and run the archetype plugin</h2>
 <p>Now you are ready to install the archetype:</p>
 <div class="source"><pre class="prettyprint linenums">
 mvn install
@@ -260,7 +260,7 @@ mvn archetype:generate
   -DartifactId=&lt;my-artifactId&gt;
 </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></section><section>
-<h3><a name="Alternative_way_to_start_creating_your_Archetype"></a>Alternative 
way to start creating your Archetype</h3>
+<h2><a name="Alternative_way_to_start_creating_your_Archetype"></a>Alternative 
way to start creating your Archetype</h2>
 <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
   -DgroupId=[your project's group id]


Reply via email to