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 Thu Feb 9
22:53:54 2023
@@ -186,33 +186,33 @@ under the License.
<li>
<p><a href="Configuring_Build_Plugins">Configuring Build Plugins</a></p></li>
<li>
-<p><a href="Using_the_.3Cexecutions.3E_Tag">Using the <executions>
Tag</a></p></li>
+<p><a href="Using_the_.3Cexecutions.3E_Tag">Using the
<code><executions></code> Tag</a></p></li>
<li>
-<p><a href="Using_the_.3Cdependencies.3E_Tag">Using the <dependencies>
Tag</a></p></li>
+<p><a href="Using_the_.3Cdependencies.3E_Tag">Using the
<code><dependencies></code> Tag</a></p></li>
<li>
-<p><a href="Using_the_.3Cinherited.3E_Tag_In_Build_Plugins">Using the
<inherited> Tag In Build Plugins</a></p></li>
+<p><a href="Using_the_.3Cinherited.3E_Tag_In_Build_Plugins">Using the
<code><inherited></code> Tag In Build Plugins</a></p></li>
<li>
<p><a href="Configuring_Reporting_Plugins">Configuring Reporting
Plugins</a></p></li>
<li>
-<p><a href="Using_the_.3Creporting.3E_Tag_VS_.3Cbuild.3E_Tag">Using the
<reporting> Tag VS <build> Tag</a></p></li>
+<p><a href="Using_the_.3Creporting.3E_Tag_VS_.3Cbuild.3E_Tag">Using the
<code><reporting></code> Tag VS <code><build></code>
Tag</a></p></li>
<li>
-<p><a href="Using_the_.3CreportSets.3E_Tag">Using the <reportSets>
Tag</a></p></li>
+<p><a href="Using_the_.3CreportSets.3E_Tag">Using the
<code><reportSets></code> Tag</a></p></li>
<li>
-<p><a href="Using_the_.3Cinherited.3E_Tag_In_Reporting_Plugins">Using the
<inherited> Tag In Reporting Plugins</a></p></li>
+<p><a href="Using_the_.3Cinherited.3E_Tag_In_Reporting_Plugins">Using the
<code><inherited></code> Tag In Reporting Plugins</a></p></li>
</ul><section>
<h3>Introduction</h3>
<p>In Maven, there are two kinds of plugins, build and reporting:</p>
<ul>
<li>
-<p><strong>Build plugins</strong> are executed during the build and configured
in the <code>\<build/\></code> element.</p></li>
+<p><strong>Build plugins</strong> are executed during the build and configured
in the <code><build></code> element.</p></li>
<li>
-<p><strong>Reporting plugins</strong> are executed during the site generation
and configured in the <code>\<reporting/\></code> element.</p></li>
+<p><strong>Reporting plugins</strong> are executed during the site generation
and configured in the <code><reporting></code> element.</p></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><strong>Important Note</strong>: 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>\<build\>\<pluginManagement/\>\</build\></code>
element. Often the <pluginManagement/> element is found in the parent
POM. For reporting plugins, specify each version in the
<code>\<reporting\>\<plugins/\>\</reporting\></code> element
(and in the
<code>\<build\>\<pluginManagement/\>\</build\></code> element
too).</p></section><section>
+<p><strong>Important Note</strong>: 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><build><pluginManagement><build></code> element. Often
the <code><pluginManagement></code> element is found in the parent POM.
For reporting plugins, specify each version in the
<code><reporting><plugins><reporting></code> element (and in
the <code><build><pluginManagement><build></code> element
too).</p></section><section>
<h3>Generic Configuration</h3>
-<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, 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>
+<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, 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"><code>@Mojo( name =
"query" )
public class MyQueryMojo
@@ -259,7 +259,7 @@ public class MyQueryMojo
</project>
</code></pre></div>
<p>The elements in the configuration match the names of the fields in the
Mojo. The mapping is 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 <em>expression</em> 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>
+<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 <em>expression</em> 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"><code>mvn myquery:query
-Dquery.url=http://maven.apache.org
</code></pre></div>
@@ -273,7 +273,7 @@ public class MyQueryMojo
<h4>Configuring Parameters</h4>
<p>Parametrisation of Mojos is relying internally on Plexus Component
Configuration API provided by <a href="https://github.com/eclipse/sisu.plexus";
class="externalLink">sisu-plexus</a>.</p><section>
<h5>Mapping Value Objects</h5>
-<p>Mapping value types, like Boolean or Integer, is very simple. The
<code>\<configuration\></code> element might look like the following:</p>
+<p>Mapping value 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"><code><project>
...
@@ -348,7 +348,7 @@ public class MyQueryMojo
</table>
</section><section>
<h5>Mapping Complex Objects</h5>
-<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>\<configuration/\></code> element might look like the
following:</p>
+<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><configuration></code> element might look like the
following:</p>
<div class="source"><pre class="prettyprint linenums"><code><project>
...
@@ -495,9 +495,9 @@ public class MyQueryMojo
</code></pre></div>
<p>In contrast to value objects and collections/arrays there is no string
coercion defined for properties, i.e. you cannot give parameters of those type
via CLI argument.</p></section></section></section><section>
<h3>Configuring Build Plugins</h3>
-<p>The following is only to configure Build plugins in the
<code>\<build\></code> element.</p><section>
-<h4>Using the <code>\<executions\></code> Tag</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>
+<p>The following is only to configure Build plugins in the
<code><build></code> element.</p><section>
+<h4>Using the <code><executions></code> Tag</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"><code><project>
...
@@ -545,7 +545,7 @@ public class MyQueryMojo
...
</project>
</code></pre></div>
-<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>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 <code>execution2</code> to a phase.</p>
@@ -607,7 +607,7 @@ public class MyBoundQueryMojo
}
}
</code></pre></div>
-<p>From the above mojo example, <code>MyBoundQueryMojo</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>
+<p>From the above mojo example, <code>MyBoundQueryMojo</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"><code><project>
...
@@ -641,13 +641,13 @@ public class MyBoundQueryMojo
</project>
</code></pre></div>
<p>Now, <code>MyBoundQueryMojo</code> default phase which is package has been
overridden by install phase.</p>
-<p><strong>Note:</strong> 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>
+<p><strong>Note:</strong> 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"><code>mvn
myquery:query@execution1
</code></pre></div></section><section>
-<h4>Using the <code>\<dependencies\></code> Tag</h4>
+<h4>Using the <code><dependencies></code> Tag</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 <code>\<dependencies\></code> 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"><code><project>
...
@@ -676,8 +676,8 @@ public class MyBoundQueryMojo
...
</project>
</code></pre></div></section><section>
-<h4>Using the <code>\<inherited\></code> Tag In Build Plugins</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>
+<h4>Using the <code><inherited></code> Tag In Build Plugins</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"><code><project>
...
@@ -696,13 +696,13 @@ public class MyBoundQueryMojo
</project>
</code></pre></div></section></section><section>
<h3>Configuring Reporting Plugins</h3>
-<p>The following is only to configure Reporting plugins in the
<code>\<reporting\></code> element.</p><section>
-<h4>Using the <code>\<reporting\></code> Tag VS
<code>\<build\></code> Tag</h4>
-<p>Configuring a reporting plugin in the <code>\<reporting\></code> or
<code>\<build\></code> elements in the pom does not exactly have the same
results.</p>
-<p>[<code>mvn site</code>] Since maven-site-plugin 3.4, it uses the parameters
defined in the <code>\<configuration\></code> element of each reporting
Plugin specified in the <code>\<reporting\></code> element, in addition
to the parameters defined in the <code>\<configuration\></code> element
of each plugin specified in <code>\<build\></code> (parameters from
<code>\<build\></code> section were previously ignored).</p>
-<p>[<code>mvn aplugin:areportgoal</code>] It <strong>ignores</strong> the
parameters defined in the <code>\<configuration\></code> element of each
reporting Plugin specified in the <code>\<reporting\></code> element;
only parameters defined in the <code>\<configuration\></code> element of
each plugin specified in <code>\<build\></code> are
used.</p></section><section>
-<h4>Using the <code>\<reportSets\></code> Tag</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>
+<p>The following is only to configure Reporting plugins in the
<code><reporting></code> element.</p><section>
+<h4>Using the <code><reporting></code> Tag VS <code><build></code>
Tag</h4>
+<p>Configuring a reporting plugin in the <code><reporting></code> or
<code><build></code> elements in the pom does not exactly have the same
results.</p>
+<p>[<code>mvn site</code>] Since maven-site-plugin 3.4, it uses the parameters
defined in the <code><configuration></code> element of each reporting
Plugin specified in the <code><reporting></code> element, in addition to
the parameters defined in the <code><configuration></code> element of
each plugin specified in <code><build></code> (parameters from
<code><build></code> section were previously ignored).</p>
+<p>[<code>mvn aplugin:areportgoal</code>] It <strong>ignores</strong> the
parameters defined in the <code><configuration></code> element of each
reporting Plugin specified in the <code><reporting></code> element; only
parameters defined in the <code><configuration></code> element of each
plugin specified in <code><build></code> are used.</p></section><section>
+<h4>Using the <code><reportSets></code> Tag</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"><code><project>
...
@@ -735,8 +735,8 @@ public class MyBoundQueryMojo
</reportSets>
</code></pre></div>
<p>1 Refer to each Plugin Documentation (i.e. plugin-info.html) to know the
available report goals.</p></section><section>
-<h4>Using the <code>\<inherited\></code> Tag In Reporting Plugins</h4>
-<p>Similar to the build plugins, to break the inheritance, you can use the
<code>\<inherited\></code> tag:</p>
+<h4>Using the <code><inherited></code> Tag In Reporting Plugins</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"><code><project>
...
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 Thu Feb 9
22:53:54 2023
@@ -224,11 +224,11 @@ under the License.
<ul>
<li>
-<p><code>\<requiredProperties\></code> : List of required properties to
generate a project from this archetype</p></li>
+<p><code><requiredProperties></code> : List of required properties to
generate a project from this archetype</p></li>
<li>
-<p><code>\<fileSets\></code> : File sets definition</p></li>
+<p><code><fileSets></code> : File sets definition</p></li>
<li>
-<p><code>\<modules\></code> : Modules definition</p></li>
+<p><code><modules></code> : Modules definition</p></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>
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 Thu Feb
9 22:53:54 2023
@@ -174,7 +174,7 @@ under the License.
<p>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.</p></li>
</ul><section>
<h3>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>
+<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>Example: Command-line variant invocation of the assembly plugin</h4>
<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>
Modified: maven/website/content/guides/mini/guide-http-settings.html
==============================================================================
--- maven/website/content/guides/mini/guide-http-settings.html (original)
+++ maven/website/content/guides/mini/guide-http-settings.html Thu Feb 9
22:53:54 2023
@@ -296,7 +296,7 @@ the target server's authentication.
problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
</code></pre></div>
<p>Without this setting, PUT requests that require authentication transfer
their entire payload to the server before that server issues an authentication
challenge. In order to complete the PUT request, the client must then re-send
the payload with the proper credentials specified in the HTTP headers. This
results in twice the bandwidth usage, and twice the time to transfer each
artifact.</p>
-<p>Another option to avoid this double transfer is what's known as preemptive
authentication, which involves sending the authentication headers along with
the original PUT request. However, there are a few potential issues with this
approach. For one thing, in the event you have an unused
<code>\<server\></code> entry that specifies an invalid username/password
combination, some servers may respond with a <code>401 Unauthorized</code> even
if the server doesn't actually require any authentication for the request. In
addition, blindly sending authentication credentials with every request
regardless of whether the server has made a challenge can result in a security
hole, since the server may not make provisions to secure credentials for paths
that don't require authentication.</p>
+<p>Another option to avoid this double transfer is what's known as preemptive
authentication, which involves sending the authentication headers along with
the original PUT request. However, there are a few potential issues with this
approach. For one thing, in the event you have an unused
<code><server></code> entry that specifies an invalid username/password
combination, some servers may respond with a <code>401 Unauthorized</code> even
if the server doesn't actually require any authentication for the request. In
addition, blindly sending authentication credentials with every request
regardless of whether the server has made a challenge can result in a security
hole, since the server may not make provisions to secure credentials for paths
that don't require authentication.</p>
<p>We'll discuss preemptive authentication in another example,
below.</p></section><section>
<h4>Configuring GET, HEAD, PUT, or All of the Above</h4>
<p>In all of the examples below, it's important to understand that you can
configure the HTTP settings for all requests made to a given server, or for
only one method. To configure all methods for a server, use the following
section of the <code>settings.xml</code> file:</p>
@@ -335,7 +335,7 @@ problems with HTTP servers and proxies t
</servers>
</settings>
</code></pre></div>
-<p>For clarity, the other two sections are <code>\<get\></code> for GET
requests, and <code>\<head\></code> for HEAD requests. I know that's
going to be hard to remember…</p></section><section>
+<p>For clarity, the other two sections are <code><get></code> for GET
requests, and <code><head></code> for HEAD requests. I know that's going
to be hard to remember…</p></section><section>
<h4>Taking Control of Your HTTP Headers</h4>
<p>As you may have noticed above, the default HTTP headers do have the
potential to cause problems. For instance, some websites set the encoding for
downloading GZipped files as <code>gzip</code>, in spite of the fact that the
HTTP request itself isn't being sent using GZip compression. If the client is
using the <code>Accept-Encoding: gzip</code> header, this can result in the
client itself decompressing the GZipped file <em>during the transfer</em> and
writing the decompressed file to the local disk with the original filename.
This can be misleading to say the least, and can use up an inordinate amount of
disk space on the local computer.</p>
<p>To turn off this default behavior, simply disable the default headers.
Then, respecify the other headers that you are still interested in, like
this:</p>
@@ -384,11 +384,11 @@ problems with HTTP servers and proxies t
<p>Going beyond the power of HTTP request parameters, HttpClient provides a
host of other configuration options. In most cases, you won't need to customize
these. But in case you do, Maven provides access to specify your own
fine-grained configuration for HttpClient. Again, you can specify these
parameter customizations per-method (HEAD, GET, or PUT), or for all methods of
interacting with a given server. For a complete list of supported parameters,
see the link[2] in Resources section below.</p><section>
<h5>Non-String Parameter Values</h5>
<p>Many of the configuration parameters for HttpClient have simple string
values; however, there are important exceptions to this. In some cases, you may
need to specify boolean, integer, or long values. In others, you may even need
to specify a collection of string values. You can specify these using a simple
formatting syntax, as follows:</p>
-<p>1 <strong>booleans:</strong> <code>%b,\<value\></code></p>
-<p>1 <strong>integer:</strong> <code>%i,\<value\></code></p>
-<p>1 <strong>long:</strong> <code>%l,\<value\></code> (yes, that's an
‘L’, not a ‘1’)</p>
-<p>1 <strong>double:</strong> <code>%d,\<value\></code></p>
-<p>1 <strong>collection of strings:</strong>
<code>%c,\<value1\>,\<value2\>,\<value3\>,...</code>, which
could also be specified as:</p>
+<p>1 <strong>booleans:</strong> <code>%b,<value></code></p>
+<p>1 <strong>integer:</strong> <code>%i,<value></code></p>
+<p>1 <strong>long:</strong> <code>%l,<value></code> (yes, that's an
‘L’, not a ‘1’)</p>
+<p>1 <strong>double:</strong> <code>%d,<value></code></p>
+<p>1 <strong>collection of strings:</strong>
<code>%c,<value1>,<value2>,<value3>,...</code>, which could
also be specified as:</p>
<div class="source"><pre class="prettyprint linenums"><code>%c,
<value1>,
@@ -516,7 +516,7 @@ problems with HTTP servers and proxies t
</servers>
</settings>
</code></pre></div>
-<p>If all you need is a per-server timeout configuration, you still have the
option to use the old <code>\<timeout\></code> parameter. If you need to
separate timeout preferences according to HTTP method, you can use one more
like that specified directly above.</p></section><section>
+<p>If all you need is a per-server timeout configuration, you still have the
option to use the old <code><timeout></code> parameter. If you need to
separate timeout preferences according to HTTP method, you can use one more
like that specified directly above.</p></section><section>
<h5>Read time out</h5>
<p>With Wagon 2.0 and Apache Maven 3.0.4, a default timeout of 30 minutes
comes by default. If you want to change this value, you can add the following
setup in your settings:</p>
Modified:
maven/website/content/guides/mini/guide-large-scale-centralized-deployments.html
==============================================================================
---
maven/website/content/guides/mini/guide-large-scale-centralized-deployments.html
(original)
+++
maven/website/content/guides/mini/guide-large-scale-centralized-deployments.html
Thu Feb 9 22:53:54 2023
@@ -231,8 +231,8 @@ under the License.
</code></pre></div></section><section>
<h3>Managing Uploads to the Repository Manager</h3>
<p>All proprietary artifacts produced by Maven projects in the organization
should be uploaded to the repository manager's hosted repositories.</p>
-<p>The <a href="../../plugins/maven-deploy-plugin">Maven Deploy Plugin</a> can
be instructed to upload artifacts to the repository manager's repositories by
defining the <code>alt\*DeploymentRepository</code> properties in the Maven
<code>settings.xml</code> file. When these properties are defined, the Maven
Deploy Plugin's <a
href="../../plugins/maven-deploy-plugin/deploy-mojo.html">deploy</a> goal uses
them instead of the <code>\<distributionManagement\></code> section of
<code>pom.xml</code> files to determine where to upload artifacts.</p>
-<p>Defining the upload destination of artifacts in <code>settings.xml</code>
files rather than in the <code>\<distributionManagement\></code> section
of <code>pom.xml</code> files allows the destinations to be centrally managed,
which simplifies maintenance if the destinations need to change. In other
words, rather than changing a huge number of <code>pom.xml</code> files, you
just need to change <a href="Settings_File_Locations">relatively few</a>
<code>settings.xml</code> files if/when the distribution locations need to
change.</p>
+<p>The <a href="../../plugins/maven-deploy-plugin">Maven Deploy Plugin</a> can
be instructed to upload artifacts to the repository manager's repositories by
defining the <code>alt\*DeploymentRepository</code> properties in the Maven
<code>settings.xml</code> file. When these properties are defined, the Maven
Deploy Plugin's <a
href="../../plugins/maven-deploy-plugin/deploy-mojo.html">deploy</a> goal uses
them instead of the <code><distributionManagement></code> section of
<code>pom.xml</code> files to determine where to upload artifacts.</p>
+<p>Defining the upload destination of artifacts in <code>settings.xml</code>
files rather than in the <code><distributionManagement></code> section of
<code>pom.xml</code> files allows the destinations to be centrally managed,
which simplifies maintenance if the destinations need to change. In other
words, rather than changing a huge number of <code>pom.xml</code> files, you
just need to change <a href="Settings_File_Locations">relatively few</a>
<code>settings.xml</code> files if/when the distribution locations need to
change.</p>
<p>The ability to specify separate alternate deployment repositories for
releases and snapshots via the <code>altReleaseDeploymentRepository</code> and
<code>altSnapshotDeploymentRepository</code> properties, respectively, was
added in Maven Deploy Plugin 2.8. To get the most out of the approach defined
in this document, all projects should use Maven Deploy Plugin >=2.8. If some
projects are still using an older version of Maven Deploy Plugin (>=2.3 and
<2.8), then specify a single alternate deployment repository via the
<code>altDeploymentRepository</code> property that points to a repository
capable of containing both releases and snapshots.</p>
<p>Typically, only continuous integration servers are allowed to upload
artifacts to the repository manager. Therefore, these settings should only be
specified in <code>settings.xml</code> files on continuous integration servers,
and should not be in <code>settings.xml</code> files on developer machines.
Alternatively, if you want developers to be able to upload artifacts to the
repository manager, then include these properties in the
<code>settings.xml</code> files used by developers.</p>
<p>Example: To upload artifacts to one of the corporate repository manager's
hosted repositories:</p>
Modified: maven/website/content/guides/mini/guide-maven-classloading.html
==============================================================================
--- maven/website/content/guides/mini/guide-maven-classloading.html (original)
+++ maven/website/content/guides/mini/guide-maven-classloading.html Thu Feb 9
22:53:54 2023
@@ -215,13 +215,13 @@ under the License.
<p>This has been introduced with Maven 3.3.1 (<a
href="https://issues.apache.org/jira/browse/MNG-5771";
class="externalLink">MNG-5771</a>).</p></section><section>
<h3>Build Extension Classloaders</h3>
<p><img src="../../buildExtensionClassRealm.svg" alt="" />Build Extension
Class Realm</p>
-<p>For every plugin which is marked with
<code>\<extensions\>true\</extensions\></code> or a build extension
listed in the according section of the POM, there is a dedicated classloader.
Those are isolated. That is, one build extension does not have access to other
build extensions. It imports everything from the API classloader. All JSR 330
or Plexus components declared in the underlying JAR are registered as
components in the global Plexus container while creating the classloader. In
addition all component references in the plugin descriptor are properly wired
from the underlying Plexus container. Build extensions have limited effect as
they are loaded late.</p></section><section>
+<p>For every plugin which is marked with
<code><extensions>true</extensions></code> or a build extension
listed in the according section of the POM, there is a dedicated classloader.
Those are isolated. That is, one build extension does not have access to other
build extensions. It imports everything from the API classloader. All JSR 330
or Plexus components declared in the underlying JAR are registered as
components in the global Plexus container while creating the classloader. In
addition all component references in the plugin descriptor are properly wired
from the underlying Plexus container. Build extensions have limited effect as
they are loaded late.</p></section><section>
<h3>Project Classloaders</h3>
<p>There is one project classloader per Maven project (identified through its
coordinates). This one imports the API Classloader. In addition it exposes all
classes from all Build Extension Classloaders which are bound to the current
project. This is only released with the container. During the build outside
Mojo executions, the thread's context classloader is set to the project
classloader.</p></section><section>
<h3>Plugin Classloaders</h3>
<p><img src="../../pluginClassRealm.svg" alt="" />Plugin Class Realm</p>
<p>Each plugin (which is not marked as build extension) has its own
classloader that imports the Project classloader.</p>
-<p>Plugins marked with
<code>\<extensions\>true\</extensions\></code> leverage the Build
Extension classloader instead of the Plugin classloader.</p>
+<p>Plugins marked with <code><extensions>true</extensions></code>
leverage the Build Extension classloader instead of the Plugin classloader.</p>
<p>Users can add dependencies to this classloader by adding dependencies to a
plugin in the
<code>[plugins/plugin](/ref/current/maven-model/maven.html#class_plugin)</code>
section of their project <code>pom.xml</code>. Here is a sample of adding
<code>ant-nodeps</code> to the plugin classloader of the Antrun Plugin and
hereby enabling the use of additional/optional Ant tasks:</p>
<div class="source"><pre class="prettyprint linenums"><code>
<plugin>
Modified: maven/website/content/guides/mini/guide-mirror-settings.html
==============================================================================
--- maven/website/content/guides/mini/guide-mirror-settings.html (original)
+++ maven/website/content/guides/mini/guide-mirror-settings.html Thu Feb 9
22:53:54 2023
@@ -198,7 +198,7 @@ under the License.
...
</settings>
</code></pre></div>
-<p>Note that there can be at most one mirror for a given repository. In other
words, you cannot map a single repository to a group of mirrors that all define
the same <code>\<mirrorOf\></code> value. Maven will not aggregate the
mirrors but simply picks the first match. If you want to provide a combined
view of several repositories, use a <a
href="../../repository-management.html">repository manager</a> instead.</p>
+<p>Note that there can be at most one mirror for a given repository. In other
words, you cannot map a single repository to a group of mirrors that all define
the same <code><mirrorOf></code> value. Maven will not aggregate the
mirrors but simply picks the first match. If you want to provide a combined
view of several repositories, use a <a
href="../../repository-management.html">repository manager</a> instead.</p>
<p>The settings descriptor documentation can be found on the <a
href="../../maven-settings/settings.html">Maven Local Settings Model
Website</a>.</p>
<p><strong>Note</strong>: The official Maven repository is at
<code>https://repo.maven.apache.org/maven2</code> hosted by the Sonatype
Company and is distributed worldwide via CDN.</p>
<p>A list of known mirrors is available in the <a
href="https://repo.maven.apache.org/maven2/.meta/repository-metadata.xml";
class="externalLink">Repository Metadata</a>. These mirrors may not have the
same contents and we don't support them in any way.</p></section><section>
@@ -236,20 +236,20 @@ under the License.
<li>
<p>an exclamation mark may be used in conjunction with one of the above
wildcards to exclude a repository id</p></li>
</ul>
-<p>Be careful not to include extra whitespace around identifiers or wildcards
in comma separated lists. For example, a mirror with
<code>\<mirrorOf</code>> set to <code>!repo1, \*</code> will not mirror
anything while <code>!repo1,\*</code> will mirror everything but
<code>repo1</code>.</p>
+<p>Be careful not to include extra whitespace around identifiers or wildcards
in comma separated lists. For example, a mirror with
<code><mirrorOf</code>> set to <code>!repo1, *</code> will not mirror
anything while <code>!repo1,*</code> will mirror everything but
<code>repo1</code>.</p>
<p>The position of wildcards within a comma separated list of repository
identifiers is not important as the wildcards defer to further processing and
explicit includes or excludes stop the processing, overruling any wildcard
match.</p>
-<p>When you use the advanced syntax and configure multiple mirrors, the
declaration order matters. When Maven looks for a mirror of some repository, it
first checks for a mirror whose <code>\<mirrorOf\></code> exactly matches
the repository identifier. If no direct match is found, Maven picks the first
mirror declaration that matches according to the rules above (if any). Hence,
you may influence match order by changing the order of the definitions in the
<code>settings.xml</code></p>
+<p>When you use the advanced syntax and configure multiple mirrors, the
declaration order matters. When Maven looks for a mirror of some repository, it
first checks for a mirror whose <code><mirrorOf></code> exactly matches
the repository identifier. If no direct match is found, Maven picks the first
mirror declaration that matches according to the rules above (if any). Hence,
you may influence match order by changing the order of the definitions in the
<code>settings.xml</code></p>
<p>Examples:</p>
<ul>
<li>
-<p><code>\*</code> = everything</p></li>
+<p><code>*</code> = everything</p></li>
<li>
-<p><code>external:\*</code> = everything not on the localhost and not file
based.</p></li>
+<p><code>external:*</code> = everything not on the localhost and not file
based.</p></li>
<li>
<p><code>repo,repo1</code> = repo or repo1</p></li>
<li>
-<p><code>\*,!repo1</code> = everything except repo1</p></li>
+<p><code>*,!repo1</code> = everything except repo1</p></li>
</ul>
<div class="source"><pre class="prettyprint linenums"><code><settings>
Modified: maven/website/content/guides/mini/guide-multiple-modules.html
==============================================================================
--- maven/website/content/guides/mini/guide-multiple-modules.html (original)
+++ maven/website/content/guides/mini/guide-multiple-modules.html Thu Feb 9
22:53:54 2023
@@ -201,7 +201,7 @@ under the License.
<li>
<p>a build extension declaration on another module in the build</p></li>
<li>
-<p>the order declared in the <code>\<modules\></code> element (if no
other rule applies)</p></li>
+<p>the order declared in the <code><modules></code> element (if no other
rule applies)</p></li>
</ul>
<p>Note that only “instantiated” references are used -
<code>dependencyManagement</code> and <code>pluginManagement</code> elements do
not cause a change to the reactor sort order.</p></section><section>
<h4>Command Line Options</h4>
Modified: maven/website/content/guides/mini/guide-releasing.html
==============================================================================
--- maven/website/content/guides/mini/guide-releasing.html (original)
+++ maven/website/content/guides/mini/guide-releasing.html Thu Feb 9 22:53:54
2023
@@ -356,7 +356,7 @@ checkpoint.check-in-development-version=
</ul></section><section>
<h3>Troubleshooting</h3><section>
<h4>I get a “The authenticity of host ‘<em>host</em>’
can't be established.” error and the build hangs</h4>
-<p>This is because your <code>\~user/.ssh/known_hosts</code> file doesn't have
the host listed. You'd normally get a prompt to add the host to the known host
list but Maven doesn't propagate that prompt. The solution is to add the host
the <code>known_hosts</code> file before executing Maven. On Windows, this can
be done by installing an OpenSSH client (for example <a
href="http://sshwindows.sourceforge.net/download/";
class="externalLink">SSHWindows</a>), running <code>ssh \<host</code>>
and accepting to add the host.</p></section><section>
+<p>This is because your <code>\~user/.ssh/known_hosts</code> file doesn't have
the host listed. You'd normally get a prompt to add the host to the known host
list but Maven doesn't propagate that prompt. The solution is to add the host
the <code>known_hosts</code> file before executing Maven. On Windows, this can
be done by installing an OpenSSH client (for example <a
href="http://sshwindows.sourceforge.net/download/";
class="externalLink">SSHWindows</a>), running <code>ssh <host></code> and
accepting to add the host.</p></section><section>
<h4>The site deploy goal hangs</h4>
<p>First, this means that you have successfully deployed the artifacts to the
remote repo and that it's only the site deployment that is now an issue. Stop
your build, cd to <strong>target/checkout</strong>> and run the build again
by executing <code>mvn site:deploy</code>. You should see a prompt asking you
to enter a password. This happens if your key is not in the authorized keys on
the server.</p></section></section></section></section>
</main>
Modified: maven/website/content/guides/mini/guide-site.html
==============================================================================
--- maven/website/content/guides/mini/guide-site.html (original)
+++ maven/website/content/guides/mini/guide-site.html Thu Feb 9 22:53:54 2023
@@ -228,9 +228,9 @@ under the License.
<ul>
<li>
-<p>the <code>\<id\></code> element identifies the repository, so that
you can attach credentials to it in your <code>settings.xml</code> file using
the <a href="../../settings.html#Servers"><code>\<servers\></code>
element</a> as you would for any other repository,</p></li>
+<p>the <code><id></code> element identifies the repository, so that you
can attach credentials to it in your <code>settings.xml</code> file using the
<a href="../../settings.html#Servers"><code><servers></code> element</a>
as you would for any other repository,</p></li>
<li>
-<p>the <code>\<url\></code> gives the location to deploy to. Currently,
only SSH is supported by default, as above which copies to the host
<code>www.mycompany.com</code> in the path <code>/www/docs/project/</code>, but
you can <a
href="/plugins/maven-site-plugin/examples/adding-deploy-protocol.html">add more
protocols as required</a>. If subprojects inherit the site URL from a parent
POM, they will automatically get their <code>\<artifactId\></code>
appended to form their effective deployment location.</p></li>
+<p>the <code><url></code> gives the location to deploy to. Currently,
only SSH is supported by default, as above which copies to the host
<code>www.mycompany.com</code> in the path <code>/www/docs/project/</code>, but
you can <a
href="/plugins/maven-site-plugin/examples/adding-deploy-protocol.html">add more
protocols as required</a>. If subprojects inherit the site URL from a parent
POM, they will automatically get their <code><artifactId></code> appended
to form their effective deployment location.</p></li>
</ul>
<p>Once distribution location is configured, deploying the site is done by
using the <code>site-deploy</code> phase of the site lifecycle.</p>
@@ -292,7 +292,7 @@ under the License.
</project>
</code></pre></div><!-- TODO: deserves more explanation. -->
-<p><strong>Note:</strong> The <code>\<menu
ref\="reports"/\></code> element above. When building the site,
this is replaced by a menu with links to all the reports that you have
configured.</p>
+<p><strong>Note:</strong> The <code><menu
ref="reports"></code> element above. When building the site, this
is replaced by a menu with links to all the reports that you have
configured.</p>
<p>More information about the site descriptor is available at the <a
href="/plugins/maven-site-plugin/examples/sitedescriptor.html">dedicated page
of Maven Site Plugin</a>.</p></section><section>
<h3>Adding Extra Resources</h3>
<p>You can add any arbitrary resource to your site by including them in a
<code>resources</code> directory as shown below. Additional CSS files will be
picked up when they are placed in the <code>css</code> directory within the
<code>resources</code> directory.</p>
@@ -329,7 +329,7 @@ under the License.
<p>License</p></li>
</ul>
<p>To find out more please refer to the <a
href="../../plugins/maven-project-info-reports-plugin/">Project Info Reports
Plugin</a>.</p>
-<p>To add these reports to your site, you must add the Project Info Reports
plugin to a special <code>\<reporting\></code> section in the POM. The
following example shows how to configure the standard project information
reports that display information from the POM in a friendly format:</p>
+<p>To add these reports to your site, you must add the Project Info Reports
plugin to a special <code><reporting></code> section in the POM. The
following example shows how to configure the standard project information
reports that display information from the POM in a friendly format:</p>
<div class="source"><pre class="prettyprint linenums"><code><project>
...
@@ -345,7 +345,7 @@ under the License.
...
</project>
</code></pre></div>
-<p>If you have included the appropriate <code>\<menu
ref\="reports"/\></code> tag in your <code>site.xml</code>
descriptor, then when you regenerate the site those items will appear in the
menu.</p>
+<p>If you have included the appropriate <code><menu
ref="reports"></code> tag in your <code>site.xml</code>
descriptor, then when you regenerate the site those items will appear in the
menu.</p>
<p>Many other plugins provide reporting goals: look for “R”
(Reporting) value in the “Type” column of the <a
href="/plugins/">list of plugins</a>. When plugins are both Build and Reporting
plugins, defining explicitely the version in the reporting section is usually
not necessary since reporting will use the version from
<code>build/plugins</code> or <code>build/pluginManagement</code>. Since Maven
Site Plugin 3.4, reporting plugin also get configuration from
<code>build/pluginManagement</code>.</p>
<p><strong>Note:</strong> Many report plugins provide a parameter called
<code>outputDirectory</code> or similar to specify the destination for their
report outputs. This parameter is only relevant if the report plugin is run
standalone, i.e. by invocation directly from the command line. In contrast,
when reports are generated as part of the site, the configuration of the Maven
Site Plugin will determine the effective output directory to ensure that all
reports end up in a central location.</p><!-- TODO: explain report sets -->
</section><section>
Modified: maven/website/content/guides/mini/guide-using-extensions.html
==============================================================================
--- maven/website/content/guides/mini/guide-using-extensions.html (original)
+++ maven/website/content/guides/mini/guide-using-extensions.html Thu Feb 9
22:53:54 2023
@@ -185,7 +185,7 @@ under the License.
<li>
<p>Registered via extension jar in
<code>$\{maven.home\}/lib/ext</code></p></li>
<li>
-<p>Registered via CLI argument <code>mvn
-Dmaven.ext.class.path\=extension.jar</code></p></li>
+<p>Registered via CLI argument <code>mvn
-Dmaven.ext.class.path=extension.jar</code></p></li>
<li>
<p>Registered via <a
href="../../configure.html#mvn-extensions-xml-file"><code>.mvn/extensions.xml</code>
file</a></p></li>
</ul></section><section>
Modified: maven/website/content/guides/mini/guide-using-toolchains.html
==============================================================================
--- maven/website/content/guides/mini/guide-using-toolchains.html (original)
+++ maven/website/content/guides/mini/guide-using-toolchains.html Thu Feb 9
22:53:54 2023
@@ -281,8 +281,8 @@ under the License.
...
</plugins>
</code></pre></div>
-<p>As you can see in the example above, a JDK toolchain with
<code>\<version\></code> “1.5” and
<code>\<vendor\></code> “sun” is to be used. Now how does
the plugin know where this JDK is installed? This is where the
<code>toolchains.xml</code> file comes in.</p>
-<p>The <code>toolchains.xml</code> file (see below) is the configuration file
where you set the installation paths of your toolchains. This file should be
put in your <code>$\{user.home\}/.m2</code> directory. When the
<code>maven-toolchains-plugin</code> executes, it looks for the
<code>toolchains.xml</code> file, reads it and looks for a toolchain matching
the toolchains requirements configured in the plugin. In our example, that
would be a JDK toolchain with <code>\<version\></code>
“1.5” and <code>\<vendor\></code> “sun”. Once
a match is found, the plugin then stores the toolchain to be used in the
MavenSession. As you can see in our <code>toolchains.xml</code> below, there is
indeed a JDK toolchain with <code>\<version\></code> “1.5”
and <code>\<vendor\></code> “sun” configured. So when the
<code>maven-compiler-plugin</code> we've configured in our <code>pom.xml</code>
above executes, it will see th
at a JDK toolchain is set in the MavenSession and will thereby use that
toolchain (that would be the JDK installed at <code>/path/to/jdk/1.5</code> for
our example) to compile the sources.</p>
+<p>As you can see in the example above, a JDK toolchain with
<code><version></code> “1.5” and
<code><vendor></code> “sun” is to be used. Now how does the
plugin know where this JDK is installed? This is where the
<code>toolchains.xml</code> file comes in.</p>
+<p>The <code>toolchains.xml</code> file (see below) is the configuration file
where you set the installation paths of your toolchains. This file should be
put in your <code>${user.home}/.m2</code> directory. When the
<code>maven-toolchains-plugin</code> executes, it looks for the
<code>toolchains.xml</code> file, reads it and looks for a toolchain matching
the toolchains requirements configured in the plugin. In our example, that
would be a JDK toolchain with <code><version></code> “1.5”
and <code><vendor></code> “sun”. Once a match is found, the
plugin then stores the toolchain to be used in the MavenSession. As you can see
in our <code>toolchains.xml</code> below, there is indeed a JDK toolchain with
<code><version></code> “1.5” and
<code><vendor></code> “sun” configured. So when the
<code>maven-compiler-plugin</code> we've configured in our <code>pom.xml</code>
above executes, it will see that a JDK t
oolchain is set in the MavenSession and will thereby use that toolchain (that
would be the JDK installed at <code>/path/to/jdk/1.5</code> for our example) to
compile the sources.</p>
<p>Starting with <a href="/docs/3.3.1/release-notes.html">Maven 3.3.1</a> you
can put the <code>toolchains.xml</code> file wherever you like by using the
<code>--global-toolchains file</code> option but it is recommended to locate it
into <code>$\{user.home\}/.m2/</code>.</p>
<div class="source"><pre class="prettyprint linenums"><code><?xml
version="1.0" encoding="UTF-8"?>
Modified: maven/website/content/guides/mini/guide-wagon-providers.html
==============================================================================
--- maven/website/content/guides/mini/guide-wagon-providers.html (original)
+++ maven/website/content/guides/mini/guide-wagon-providers.html Thu Feb 9
22:53:54 2023
@@ -174,16 +174,16 @@ under the License.
<h2>Guide to Selecting Alternative Wagon Providers</h2>
<p>By default, Maven uses the <code>java.net.URLConnection</code>
(<code>HttpURLConnection</code>) classes provided with the JDK to access
repositories that use the HTTP/HTTPs protocols. Unfortunately, since this
implementation contains certain bugs, Maven users may find themselves unable to
connect to servers that demand some configurations. A couple examples of weird
behavior include line-wrapping the Authorization header's Base64 value when
passwords are long, and using cached values in preemptive authentication for
successive connections to the same server.</p>
<p>Maven 2.2.0 attempted to amend this problem by switching over to a Wagon
implementation that's based on Apache HttpClient. Unfortunately, it soon became
apparent that HttpClient doesn't support NTLM (at least, version 2), which
effectively means users behind NTLMv2 proxies cannot use Maven 2.2.0.</p>
-<p>To hopefully resolve this once and for all, Maven 2.2.1 will contain
support for specifying which Wagon provider you want to use for a given
protocol during the build. The provider name will then be appended to the
protocol using the format <code>\<protocol\>-\<provider\></code> to
form the component role-hint for the Wagon.</p>
-<p>As of Maven 2.2.1, there are two ways to specify which Wagon provider
should be used: via the command line, or in the <code>\<server\></code>
configuration section of the <code>settings.xml</code>.</p><section>
+<p>To hopefully resolve this once and for all, Maven 2.2.1 will contain
support for specifying which Wagon provider you want to use for a given
protocol during the build. The provider name will then be appended to the
protocol using the format <code><protocol>-<provider></code> to
form the component role-hint for the Wagon.</p>
+<p>As of Maven 2.2.1, there are two ways to specify which Wagon provider
should be used: via the command line, or in the <code><server></code>
configuration section of the <code>settings.xml</code>.</p><section>
<h3>Command-Line Configuration</h3>
-<p>To specify the Wagon provider from the command line, simply use the
<code>-Dmaven.wagon.provider.\<protocol\>\=\<provider-name\></code>
command-line option, like the following:</p>
+<p>To specify the Wagon provider from the command line, simply use the
<code>-Dmaven.wagon.provider.<protocol>=<provider-name></code>
command-line option, like the following:</p>
<div class="source"><pre class="prettyprint linenums"><code>mvn
-Dmaven.wagon.provider.http=httpclient clean install
</code></pre></div>
<p>This instructs Maven to use the HttpClient-based Wagon implementation for
connections to HTTP repositories.</p></section><section>
<h3><code>settings.xml</code> Configuration</h3>
-<p>To specify which Wagon provider to use for a particular server, modify your
<code>settings.xml</code> file to add the <code>\<wagonProvider\></code>
configuration to your <code>\<server\></code> entry, like the
following:</p>
+<p>To specify which Wagon provider to use for a particular server, modify your
<code>settings.xml</code> file to add the <code><wagonProvider></code>
configuration to your <code><server></code> entry, like the following:</p>
<div class="source"><pre class="prettyprint linenums"><code><settings>
[...]
@@ -197,7 +197,7 @@ under the License.
</server>
</code></pre></div></section><section>
<h3>Available Wagon Providers</h3>
-<p>Maven 2.2.1 provides two providers for HTTP/HTTPS Wagons:
<code>lightweight</code> and <code>httpclient</code>. If you add a new HTTP
Wagon implementation via build extension, you'll need to make sure the
extension binds its Wagon components to role-hints of the form
<code>\<protocol\>-\<provider\></code> in order to allow users to
specify your alternative Wagon provider. For instance, the HttpClient HTTP
Wagon component definition looks like this:</p>
+<p>Maven 2.2.1 provides two providers for HTTP/HTTPS Wagons:
<code>lightweight</code> and <code>httpclient</code>. If you add a new HTTP
Wagon implementation via build extension, you'll need to make sure the
extension binds its Wagon components to role-hints of the form
<code><protocol>-<provider></code> in order to allow users to
specify your alternative Wagon provider. For instance, the HttpClient HTTP
Wagon component definition looks like this:</p>
<div class="source"><pre class="prettyprint linenums"><code><component>
<role>org.apache.maven.wagon.Wagon</role>
Modified: maven/website/content/guides/plugin/guide-java-plugin-development.html
==============================================================================
--- maven/website/content/guides/plugin/guide-java-plugin-development.html
(original)
+++ maven/website/content/guides/plugin/guide-java-plugin-development.html Thu
Feb 9 22:53:54 2023
@@ -191,8 +191,8 @@ under the License.
<p><a href="Resources">Resources</a></p></li>
</ul><section>
<h3>Important Notice: <a href="../mini/guide-naming-conventions.html">Plugin
Naming Convention and Apache Maven Trademark</a></h3>
-<p>You will typically name your plugin
<code>\<yourplugin\>-maven-plugin</code>.</p>
-<p>Calling it <code>maven-\<yourplugin\>-plugin</code> (note
“Maven” is at the beginning of the plugin name) is
<strong>strongly discouraged</strong> since it's a <strong>reserved naming
pattern for official Apache Maven plugins maintained by the Apache Maven
team</strong> with groupId <code>org.apache.maven.plugins</code>. Using this
naming pattern is an infringement of the Apache Maven
Trademark.</p></section><section>
+<p>You will typically name your plugin
<code><yourplugin>-maven-plugin</code>.</p>
+<p>Calling it <code>maven-<yourplugin>-plugin</code> (note
“Maven” is at the beginning of the plugin name) is
<strong>strongly discouraged</strong> since it's a <strong>reserved naming
pattern for official Apache Maven plugins maintained by the Apache Maven
team</strong> with groupId <code>org.apache.maven.plugins</code>. Using this
naming pattern is an infringement of the Apache Maven
Trademark.</p></section><section>
<h3>Your First Plugin</h3>
<p>In this section we will build a simple plugin with one goal which takes no
parameters and simply displays a message on the screen when run. Along the way,
we will cover the basics of setting up a project to create a plugin, the
minimal contents of a Java mojo which will define goal code, and a couple ways
to execute the mojo.</p><section>
<h4>Your First Mojo</h4>
Modified:
maven/website/content/guides/plugin/guide-java-report-plugin-development.html
==============================================================================
---
maven/website/content/guides/plugin/guide-java-report-plugin-development.html
(original)
+++
maven/website/content/guides/plugin/guide-java-report-plugin-development.html
Thu Feb 9 22:53:54 2023
@@ -161,7 +161,7 @@ under the License.
<p>A plugin is actually not a <em>report plugin</em> in itself. But one (or
several) of its goals or <em>Mojos</em> may be specialized to be invoked by <a
href="/plugins/maven-site-plugin/"><code>maven-site-plugin</code></a>,
typically during the <code>site</code> build life cycle.</p>
<p>A Maven plugin can therefore implement <em>regular</em> goals and
<em>report</em> goals. The below details how to write a <em>Mojo</em> that will
get invoked as a <em>report</em> by <a
href="/plugins/maven-site-plugin/"><code>maven-site-plugin</code></a>.</p><section>
<h3>How It Works</h3>
-<p>1 A regular Maven project usually invokes <em>reporting goals</em> of a
plugin by declaring such plugin in the <a
href="/plugins/maven-site-plugin/examples/configuring-reports.html"><code>\<reporting\></code></a>
section of its <code>pom.xml</code> as in the example below:</p>
+<p>1 A regular Maven project usually invokes <em>reporting goals</em> of a
plugin by declaring such plugin in the <a
href="/plugins/maven-site-plugin/examples/configuring-reports.html"><code><reporting></code></a>
section of its <code>pom.xml</code> as in the example below:</p>
<div class="source"><pre class="prettyprint linenums"><code><project>
...
@@ -470,7 +470,7 @@ simple:simple
[INFO] ------------------------------------------------------------------------
</code></pre></div></section><section>
<h4>Invoking the Simple Plugin</h4>
-<p>To invoke the <em>report Mojo</em> of our plugin in another Maven project,
we just need to declare the plugin in the <a
href="/plugins/maven-site-plugin/examples/configuring-reports.html"><code>\<reporting\></code></a>
section of its <code>pom.xml</code> as in the example below:</p>
+<p>To invoke the <em>report Mojo</em> of our plugin in another Maven project,
we just need to declare the plugin in the <a
href="/plugins/maven-site-plugin/examples/configuring-reports.html"><code><reporting></code></a>
section of its <code>pom.xml</code> as in the example below:</p>
<div class="source"><pre class="prettyprint linenums"><code><project>
...
Modified: maven/website/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.
Modified: maven/website/content/plugin-developers/common-bugs.html
==============================================================================
--- maven/website/content/plugin-developers/common-bugs.html (original)
+++ maven/website/content/plugin-developers/common-bugs.html Thu Feb 9
22:53:54 2023
@@ -272,9 +272,9 @@ if ( "info".equals( debugLevel
+- mymojo-report_fr.properties
</code></pre></div>
<p>Now, if a resource bundle is to be looked up for English on a JVM whose
default locale happens to be French, the bundle
<code>mymojo-report_fr.properties</code> will be loaded instead of the intended
bundle <code>mymojo-report.properties</code>.</p>
-<p>Reporting plugins that suffer from this bug can easily be detected by
executing <code>mvn site -D locales\=xy,en</code> where <code>xy</code> denotes
any other language code supported by the particular plugin. Specifying
<code>xy</code> as the first locale will have the Maven Site Plugin change the
JVM's default locale to <code>xy</code> which in turn causes the lookup for
<code>en</code> to fail as outlined above unless the plugin has a dedicated
resource bundle for English.</p></section><section>
+<p>Reporting plugins that suffer from this bug can easily be detected by
executing <code>mvn site -D locales=xy,en</code> where <code>xy</code> denotes
any other language code supported by the particular plugin. Specifying
<code>xy</code> as the first locale will have the Maven Site Plugin change the
JVM's default locale to <code>xy</code> which in turn causes the lookup for
<code>en</code> to fail as outlined above unless the plugin has a dedicated
resource bundle for English.</p></section><section>
<h3>Using System Properties</h3>
-<p>Maven's command line supports the definition of system properties via
arguments of the form <code>-D key\=value</code>. While these properties are
called system properties, plugins should never use
<code>[System.getProperty()](http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String))</code>
and related methods to query these properties. For example, the following code
snippet will not work reliably when Maven is embedded, say into an IDE or a CI
server:</p>
+<p>Maven's command line supports the definition of system properties via
arguments of the form <code>-D key=value</code>. While these properties are
called system properties, plugins should never use
<code>[System.getProperty()](http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String))</code>
and related methods to query these properties. For example, the following code
snippet will not work reliably when Maven is embedded, say into an IDE or a CI
server:</p>
<div class="source"><pre class="prettyprint linenums"><code>public MyMojo
extends AbstractMojo
{
Modified: maven/website/content/plugins/index.html
==============================================================================
--- maven/website/content/plugins/index.html (original)
+++ maven/website/content/plugins/index.html Thu Feb 9 22:53:54 2023
@@ -147,9 +147,9 @@ under the License.
<ul>
<li>
-<p><strong>Build plugins</strong> will be executed during the build and they
should be configured in the <code>\<build/\></code> element from the
POM.</p></li>
+<p><strong>Build plugins</strong> will be executed during the build and they
should be configured in the <code><build></code> element from the
POM.</p></li>
<li>
-<p><strong>Reporting plugins</strong> will be executed during the site
generation and they should be configured in the
<code>\<reporting/\></code> element from the POM. Because the result of a
Reporting plugin is part of the generated site, Reporting plugins should be
both internationalized and localized. You can read more about the <a
href="./localization.html">localization of our plugins</a> and how you can
help.</p></li>
+<p><strong>Reporting plugins</strong> will be executed during the site
generation and they should be configured in the <code><reporting></code>
element from the POM. Because the result of a Reporting plugin is part of the
generated site, Reporting plugins should be both internationalized and
localized. You can read more about the <a
href="./localization.html">localization of our plugins</a> and how you can
help.</p></li>
</ul><section>
<h3>Supported By The Maven Project</h3>
<p>To see the most up-to-date list browse the Maven repository, specifically
the <a href="https://repo.maven.apache.org/maven2/org/apache/maven/plugins/";
class="externalLink"><code>org/apache/maven/plugins</code></a> subfolder.
<em>(Plugins are organized according to a directory structure that resembles
the standard Java package naming convention)</em></p><!-- TODO: the repository
manager should be able to produce a page like this. Ensure all descriptions are
in the POM of these plugins. -->
Modified: maven/website/content/repository/central-index.html
==============================================================================
--- maven/website/content/repository/central-index.html (original)
+++ maven/website/content/repository/central-index.html Thu Feb 9 22:53:54 2023
@@ -158,7 +158,7 @@ under the License.
-->
<section><section>
<h2>Central Index</h2>
-<p>Central repository provides <a
href="https://repo.maven.apache.org/maven2/.index/"; class="externalLink">an
index</a> that is updated weekly as full
(<code>nexus-maven-repository-index.gz</code>) and incremental
(<code>nexus-maven-repository-index.\<n\>.gz</code> +
<code>nexus-maven-repository-index.properties</code>).</p>
+<p>Central repository provides <a
href="https://repo.maven.apache.org/maven2/.index/"; class="externalLink">an
index</a> that is updated weekly as full
(<code>nexus-maven-repository-index.gz</code>) and incremental
(<code>nexus-maven-repository-index.<n>.gz</code> +
<code>nexus-maven-repository-index.properties</code>).</p>
<p>This index is build using <a href="/maven-indexer/">Maven Indexer</a>: see
<a href="/maven-indexer-archives/maven-indexer-LATEST/indexer-core/">LATEST
indexer-core documentation</a> for more details on the fields that are
available.</p>
<p>You can use <a
href="/maven-indexer-archives/maven-indexer-LATEST/indexer-core/apidocs/">Maven
Indexer API</a> (see <a
href="/maven-indexer-archives/maven-indexer-LATEST/indexer-examples/">examples</a>)
to use this index with a dedicated API, or use <a
href="http://lucene.apache.org/"; class="externalLink">Apache Lucene</a> indexes
browsers like <a href="https://github.com/DmitryKey/luke";
class="externalLink">Luke</a> or <a href="https://github.com/flaxsearch/marple";
class="externalLink">Marple</a> after unpacking the index (see <a
href="/maven-indexer-archives/maven-indexer-LATEST/indexer-cli/"><code>-u</code>
CLI option</a>).</p><section>
<h3>Digging Into Central Index with Luke</h3>
Modified: maven/website/content/settings.html
==============================================================================
--- maven/website/content/settings.html (original)
+++ maven/website/content/settings.html Thu Feb 9 22:53:54 2023
@@ -505,7 +505,7 @@ contain the corresponding element's valu
<li>Java System Properties: All properties accessible via
<code>java.lang.System.getProperties()</code> are available as POM properties,
such as <code>${java.home}</code>.</li>
-<li><code>x</code>: Set within a <properties /> element or an external
files, the
+<li><code>x</code>: Set within a <code><properties\></code> element or
an external files, the
value may be used as <code>${someVar}</code>.</li>
</ol><!-- -->
