Author: svn-site-role
Date: Thu Feb 9 23:13:59 2023
New Revision: 1907552
Log:
Site checkin for project Apache Maven Site
Modified:
maven/website/content/developers/committer-settings.html
maven/website/content/faq-unoffical.html
maven/website/content/guides/development/guide-testing-development-plugins.html
maven/website/content/guides/getting-started/index.html
maven/website/content/guides/getting-started/windows-prerequisites.html
maven/website/content/guides/introduction/introduction-to-plugin-prefix-mapping.html
maven/website/content/guides/introduction/introduction-to-plugins.html
maven/website/content/guides/introduction/introduction-to-profiles.html
maven/website/content/guides/introduction/introduction-to-the-pom.html
maven/website/content/guides/mini/guide-3rd-party-jars-remote.html
maven/website/content/guides/mini/guide-assemblies.html
maven/website/content/guides/mini/guide-attached-tests.html
maven/website/content/guides/mini/guide-configuring-maven.html
maven/website/content/guides/mini/guide-creating-archetypes.html
maven/website/content/guides/mini/guide-encryption.html
maven/website/content/guides/mini/guide-maven-classloading.html
maven/website/content/guides/mini/guide-mirror-settings.html
maven/website/content/guides/mini/guide-multiple-repositories.html
maven/website/content/guides/mini/guide-proxies.html
maven/website/content/guides/mini/guide-reproducible-builds.html
maven/website/content/guides/mini/guide-site.html
maven/website/content/guides/mini/guide-snippet-macro.html
maven/website/content/guides/mini/guide-using-extensions.html
maven/website/content/guides/mini/guide-using-toolchains.html
maven/website/content/guides/plugin/guide-java-plugin-development.html
maven/website/content/maven-site-1.0-site.jar
maven/website/content/plugin-developers/common-bugs.html
maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html
Modified: maven/website/content/developers/committer-settings.html
==============================================================================
--- maven/website/content/developers/committer-settings.html (original)
+++ maven/website/content/developers/committer-settings.html Thu Feb 9
23:13:59 2023
@@ -160,7 +160,7 @@ under the License.
-->
<section><section>
<h2>Introduction</h2>
-<p>This document is intended to set up the Maven committer settings, i.e. the
<code>$\{user.home\}/.m2/settings.xml</code>.</p><section>
+<p>This document is intended to set up the Maven committer settings, i.e. the
<code>${user.home}/.m2/settings.xml</code>.</p><section>
<h3>Enable Apache Servers</h3>
<p>Maven uses several servers configuration to deploy snapshots and releases
on the Apache servers. You need to tell to Maven what your Apache username
is.</p>
<p><strong>It is highly recommended to use Maven's <a
href="../guides/mini/guide-encryption.html">password encryption
capabilities</a> for your passwords</strong>.</p>
Modified: maven/website/content/faq-unoffical.html
==============================================================================
--- maven/website/content/faq-unoffical.html (original)
+++ maven/website/content/faq-unoffical.html Thu Feb 9 23:13:59 2023
@@ -308,7 +308,7 @@ under the License.
<p>So, to recap:</p>
<p>parent:</p>
-<div class="source"><pre class="prettyprint
linenums"><code><configuration>
+<div class="source"><pre class="prettyprint linenums"><code
class="language-xml"><configuration>
<items>
<item>one</item>
<item>two</item>
@@ -616,7 +616,7 @@ plugins will be available soon, currentl
<ul>
<li>Put your static pages in the resources directory,
${basedir}/src/site/resources.</li>
-<li>Create your site.xml and put it in ${basedir}/src/site. An example
below:</li>
+<li>Create your site.xml and put it in <code>${basedir}/src/site</code>. An
example below:</li>
</ul>
<div class="source"><pre class="prettyprint linenums"><code><project
name="Maven War Plugin">
@@ -877,7 +877,7 @@ We will probably try to fix this problem
<p>Also see [How do I run a build/package/deploy process without waiting for
reports or unit tests, so that I can quickly deploy to an integration box?]</p>
<p><em>Sites & Reporting, General</em></p></section><section>
<h3>How do I create a command line parameter (i.e., -Dname=value ) in my
mojo?</h3>
-<p>In your mojo, put <code>expression=$\{<exp>\}</code> in your
parameter field</p>
+<p>In your mojo, put <code>expression=${<exp>}</code> in your parameter
field</p>
<div class="source"><pre class="prettyprint linenums"><code>/**
* @parameter expression="${expression.name}"
@@ -992,7 +992,7 @@ NOTE: this may only work in the latest p
<p>Now, to specify a different output directory at runtime simply use the
directory property as a mvn command line parameter;
{code}mvn -Ddirectory=tmp package</p>
-<div class="source"><pre class="prettyprint linenums"><code>This will send the
build's output files to the $\{basedir}/tmp directory.
+<div class="source"><pre class="prettyprint linenums"><code>This will send the
build's output files to the ${basedir}/tmp directory.
_POM, Command Line_
@@ -1104,7 +1104,7 @@ e.g. mvn eclipse:help
</code></pre></div>
<p><em>Plugins and Lifecycle, IDEs</em></p></section><section>
<h3>What does aggregator mean in mojo?</h3>
-<p>When a Mojo has a <code>@aggregator</code> expression, it means that It can
only build the parent project of your multi-module-project, the one who has the
packaging of pom. It can also give you values for the expression
${reactorProjects} where reactorProjects are the MavenProject references to the
parent pom modules.</p></section><section>
+<p>When a Mojo has a <code>@aggregator</code> expression, it means that It can
only build the parent project of your multi-module-project, the one who has the
packaging of pom. It can also give you values for the expression
<code>${reactorProjects}</code> where reactorProjects are the MavenProject
references to the parent pom modules.</p></section><section>
<h3>Why there are no dependency properties in Maven?</h3>
<p>They were removed because they aren't reliable in a transitive environment.
It implies that the dependency knows something about the
environment of the dependee, which is back to front. In most cases, granted,
the value for war bundle will be the same for a particular
@@ -1235,8 +1235,8 @@ In this case the provider needed is ftp,
</code></pre></div></section><section>
<h3>How can I reference windows or unix environment variables in my POM?</h3>
<p>Starting in maven <em>2.0.1</em>, you can reference windows and unix
environment variables inside your pom.xml or settings.xml using an expression
of the form:
-<code>$\{env.VARNAME\}</code>
-So, if you wanted to reference your home directory environment variable, you
might use: <code>$\{env.HOME\}</code></p></section><section>
+<code>${env.VARNAME}</code>
+So, if you wanted to reference your home directory environment variable, you
might use: <code>${env.HOME}</code></p></section><section>
<h3>How do I know which phase a plug-in is associated with?</h3>
<p>Open the plugin's Mojo class source code and look for @phase. This tells
which phase the plugin is associated.</p></section><section>
<h3>Where to get sun.jdk-tools-jar-1.4.0 on MacOSX?</h3>
@@ -1295,7 +1295,7 @@ there is already some discussion about t
</dependency>
</code></pre></div></section><section>
<h3>How can I change the default location of the generated jar when I command
“mvn package”?</h3>
-<p>By default, the location of the generated jar is in
${project.build.directory} or in your target directory.
+<p>By default, the location of the generated jar is in
<code>${project.build.directory}</code> or in your target directory.
We can change this by configuring the outputDirectory of maven-jar-plugin.</p>
<div class="source"><pre class="prettyprint linenums"><code><plugin>
@@ -1403,7 +1403,7 @@ More info about the assembly plugin can
<p>The repositories are searched through based in the order they are defined
in your pom. The inherited repositories are always searched last.
Note: You don't have to define the central repo (i.e.
ibiblio).</p></section><section>
<h3>Is it possible to exclude a package from the generated jar file?</h3>
-<p>You can configure maven-compiler-plugin to exclude your unwanted packages
or files to be compiled in the first place. But you will not be able to prevent
javac to compile those files if they are referenced by other packages within
the source tree. To prevent that, you will need to use antrun plugin ( or write
your own custom plugin), bind it to compile phase, and remove unwanted classes
in ${project.build.directory}/classes. If possible, just move those
pacakges/files to another source tree to become another
project.</p></section><section>
+<p>You can configure maven-compiler-plugin to exclude your unwanted packages
or files to be compiled in the first place. But you will not be able to prevent
javac to compile those files if they are referenced by other packages within
the source tree. To prevent that, you will need to use antrun plugin ( or write
your own custom plugin), bind it to compile phase, and remove unwanted classes
in <code>${project.build.directory}/classes</code>. If possible, just move
those pacakges/files to another source tree to become another
project.</p></section><section>
<h3>How should I point a path for Maven to use a certain version of JDK when I
have different versions of JDK installed on my PC and my JAVA_HOME already
set?</h3>
<p>If you don't want to change your system JAVA_HOME, set it in maven script
instead.</p></section><section>
<h3>Why does release prepare goal requires the project to be released be a
snapshot? Is it possible to do a release prepare from a parent project? What
about from a sub-project?</h3>
@@ -1526,7 +1526,7 @@ I think your choice is probably influenc
pom.xml > project scope
</code></pre></div></section><section>
<h3>What is reactorProjects? executedProject?</h3>
-<p>${reactorProjects} are the projects that the current mvn command are going
to be built. This will include the parent project and all its children while
${executedProject} is the project where you typed your mvn
command.</p></section><section>
+<p><code>${reactorProjects}</code> are the projects that the current mvn
command are going to be built. This will include the parent project and all its
children while <code>${executedProject}</code> is the project where you typed
your mvn command.</p></section><section>
<h3>What is a Snapshot?</h3>
<p>A snapshot is a development version. e.g, 2.0-SNAPSHOT is the
still-in-development future 2.0.
If you want to use a snapshot, juste use <code><version></code> , e.g.
<code><version>2.0-SNAPSHOT</version></code>. But first you must
ensure that you have access to
Modified:
maven/website/content/guides/development/guide-testing-development-plugins.html
==============================================================================
---
maven/website/content/guides/development/guide-testing-development-plugins.html
(original)
+++
maven/website/content/guides/development/guide-testing-development-plugins.html
Thu Feb 9 23:13:59 2023
@@ -206,7 +206,7 @@ under the License.
<p>The development version will stop being used if the
<code><pluginRepository></code> element is removed from your POM and the
version is set back to the release version. If you are using the command line
or an unspecified version, you will also need to remove the version from the
local repository.</p></section><section>
<h3>Using Settings without Modifying the Project</h3>
<p>If you are using the goals from the command line on a number of projects,
you should include this in your <code>settings.xml</code> file instead.</p>
-<p>You need to modify your <code>$\{user.home\}/.m2/settings.xml</code> file
to include two new profiles and then when you need access to the plugin
snapshots use <code>-Papache</code>. The profile only needs to be enabled once
so that the plugins can be downloaded into you local repository. Once in your
local repository Maven can successfully resolve the dependencies and the
profile no longer needs to be activated.</p>
+<p>You need to modify your <code>${user.home}/.m2/settings.xml</code> file to
include two new profiles and then when you need access to the plugin snapshots
use <code>-Papache</code>. The profile only needs to be enabled once so that
the plugins can be downloaded into you local repository. Once in your local
repository Maven can successfully resolve the dependencies and the profile no
longer needs to be activated.</p>
<div class="source"><pre class="prettyprint linenums"><code><settings>
...
Modified: maven/website/content/guides/getting-started/index.html
==============================================================================
--- maven/website/content/guides/getting-started/index.html (original)
+++ maven/website/content/guides/getting-started/index.html Thu Feb 9 23:13:59
2023
@@ -314,7 +314,7 @@ under the License.
`-- app
`-- AppTest.java
</code></pre></div>
-<p>As you can see, the project created from the archetype has a POM, a source
tree for your application's sources and a source tree for your test sources.
This is the standard layout for Maven projects (the application sources reside
in <code>$\{basedir\}/src/main/java</code> and test sources reside in
<code>$\{basedir\}/src/test/java</code>, where ${basedir} represents the
directory containing <code>pom.xml</code>).</p>
+<p>As you can see, the project created from the archetype has a POM, a source
tree for your application's sources and a source tree for your test sources.
This is the standard layout for Maven projects (the application sources reside
in <code>${basedir}/src/main/java</code> and test sources reside in
<code>${basedir}/src/test/java</code>, where <code>${basedir}</code> represents
the directory containing <code>pom.xml</code>).</p>
<p>If you were to create a Maven project by hand this is the directory
structure that we recommend using. This is a Maven convention and to learn more
about it you can read our <a
href="../introduction/introduction-to-the-standard-directory-layout.html">Introduction
to the Standard Directory Layout</a>.</p>
<p>Now that we have a POM, some application sources, and some test sources you
are probably asking…</p></section><section>
<h3>How do I compile my application sources?</h3>
@@ -345,7 +345,7 @@ under the License.
[INFO] ------------------------------------------------------------------------
</code></pre></div>
<p>The first time you execute this (or any other) command, Maven will need to
download all the plugins and related dependencies it needs to fulfill the
command. From a clean installation of Maven, this can take quite a while (in
the output above, it took almost 4 minutes). If you execute the command again,
Maven will now have what it needs, so it won't need to download anything new
and will be able to execute the command much more quickly.</p>
-<p>As you can see from the output, the compiled classes were placed in
<code>$\{basedir\}/target/classes</code>, which is another standard convention
employed by Maven. So, if you're a keen observer, you'll notice that by using
the standard conventions, the POM above is very small and you haven't had to
tell Maven explicitly where any of your sources are or where the output should
go. By following the standard Maven conventions, you can get a lot done with
very little effort! Just as a casual comparison, let's take a look at what you
might have had to do in <a href="http://ant.apache.org"
class="externalLink">Ant</a> to accomplish the same <a
href="../../ant/build-a1.xml">thing</a>.</p>
+<p>As you can see from the output, the compiled classes were placed in
<code>${basedir}/target/classes</code>, which is another standard convention
employed by Maven. So, if you're a keen observer, you'll notice that by using
the standard conventions, the POM above is very small and you haven't had to
tell Maven explicitly where any of your sources are or where the output should
go. By following the standard Maven conventions, you can get a lot done with
very little effort! Just as a casual comparison, let's take a look at what you
might have had to do in <a href="http://ant.apache.org"
class="externalLink">Ant</a> to accomplish the same <a
href="../../ant/build-a1.xml">thing</a>.</p>
<p>Now, this is simply to compile a single tree of application sources and the
Ant script shown is pretty much the same size as the POM shown above. But we'll
see how much more we can do with just that simple POM!</p></section><section>
<h3>How do I compile my test sources and run my unit tests?</h3>
<p>Now you're successfully compiling your application's sources and now you've
got some unit tests that you want to compile and execute (because every
programmer always writes and executes their unit tests *nudge nudge wink
wink*).</p>
@@ -413,8 +413,8 @@ under the License.
<div class="source"><pre class="prettyprint linenums"><code>mvn package
</code></pre></div>
-<p>You can now take a look in the <code>$\{basedir\}/target</code> directory
and you will see the generated JAR file.</p>
-<p>Now you'll want to install the artifact you've generated (the JAR file) in
your local repository (<code>$\{user.home\}/.m2/repository</code> is the
default location). For more information on repositories you can refer to our <a
href="../introduction/introduction-to-repositories.html">Introduction to
Repositories</a> but let's move on to installing our artifact! To do so execute
the following command:</p>
+<p>You can now take a look in the <code>${basedir}/target</code> directory and
you will see the generated JAR file.</p>
+<p>Now you'll want to install the artifact you've generated (the JAR file) in
your local repository (<code>${user.home}/.m2/repository</code> is the default
location). For more information on repositories you can refer to our <a
href="../introduction/introduction-to-repositories.html">Introduction to
Repositories</a> but let's move on to installing our artifact! To do so execute
the following command:</p>
<div class="source"><pre class="prettyprint linenums"><code>mvn install
</code></pre></div>
@@ -530,7 +530,7 @@ under the License.
<p>To find out what configuration is available for a plugin, you can see the
<a href="../../plugins/">Plugins List</a> and navigate to the plugin and goal
you are using. For general information about how to configure the available
parameters of a plugin, have a look at the <a
href="../mini/guide-configuring-plugins.html">Guide to Configuring
Plugins</a>.</p></section><section>
<h3>How do I add resources to my JAR?</h3>
<p>Another common use case that can be satisfied which requires no changes to
the POM that we have above is packaging resources in the JAR file. For this
common task, Maven again relies on the <a
href="../introduction/introduction-to-the-standard-directory-layout.html">Standard
Directory Layout</a>, which means by using standard Maven conventions you can
package resources within JARs simply by placing those resources in a standard
directory structure.</p>
-<p>You see below in our example we have added the directory
<code>$\{basedir\}/src/main/resources</code> into which we place any resources
we wish to package in our JAR. The simple rule employed by Maven is this: any
directories or files placed within the
<code>$\{basedir\}/src/main/resources</code> directory are packaged in your JAR
with the exact same structure starting at the base of the JAR.</p>
+<p>You see below in our example we have added the directory
<code>${basedir}/src/main/resources</code> into which we place any resources we
wish to package in our JAR. The simple rule employed by Maven is this: any
directories or files placed within the
<code>${basedir}/src/main/resources</code> directory are packaged in your JAR
with the exact same structure starting at the base of the JAR.</p>
<div class="source"><pre class="prettyprint linenums"><code>my-app
|-- pom.xml
@@ -566,7 +566,7 @@ under the License.
`-- app
`-- App.class
</code></pre></div>
-<p>As you can see, the contents of
<code>$\{basedir\}/src/main/resources</code> can be found starting at the base
of the JAR and our <code>application.properties</code> file is there in the
<code>META-INF</code> directory. You will also notice some other files there
like <code>META-INF/MANIFEST.MF</code> as well as a <code>pom.xml</code> and
<code>pom.properties</code> file. These come standard with generation of a JAR
in Maven. You can create your own manifest if you choose, but Maven will
generate one by default if you don't. (You can also modify the entries in the
default manifest. We will touch on this later.) The <code>pom.xml</code> and
<code>pom.properties</code> files are packaged up in the JAR so that each
artifact produced by Maven is self-describing and also allows you to utilize
the metadata in your own application if the need arises. One simple use might
be to retrieve the version of your application. Operating on the POM file would
require you to use some Maven utiliti
es but the properties can be utilized using the standard Java API and look
like the following:</p>
+<p>As you can see, the contents of <code>${basedir}/src/main/resources</code>
can be found starting at the base of the JAR and our
<code>application.properties</code> file is there in the <code>META-INF</code>
directory. You will also notice some other files there like
<code>META-INF/MANIFEST.MF</code> as well as a <code>pom.xml</code> and
<code>pom.properties</code> file. These come standard with generation of a JAR
in Maven. You can create your own manifest if you choose, but Maven will
generate one by default if you don't. (You can also modify the entries in the
default manifest. We will touch on this later.) The <code>pom.xml</code> and
<code>pom.properties</code> files are packaged up in the JAR so that each
artifact produced by Maven is self-describing and also allows you to utilize
the metadata in your own application if the need arises. One simple use might
be to retrieve the version of your application. Operating on the POM file would
require you to use some Maven utilities
but the properties can be utilized using the standard Java API and look like
the following:</p>
<div class="source"><pre class="prettyprint linenums"><code>#Generated by Maven
#Tue Oct 04 15:43:21 GMT-05:00 2005
@@ -574,7 +574,7 @@ version=1.0-SNAPSHOT
groupId=com.mycompany.app
artifactId=my-app
</code></pre></div>
-<p>To add resources to the classpath for your unit tests, you follow the same
pattern as you do for adding resources to the JAR except the directory you
place resources in is ${basedir}/src/test/resources. At this point you would
have a project directory structure that would look like the following:</p>
+<p>To add resources to the classpath for your unit tests, you follow the same
pattern as you do for adding resources to the JAR except the directory you
place resources in is <code>${basedir}/src/test/resources</code>. At this point
you would have a project directory structure that would look like the
following:</p>
<div class="source"><pre class="prettyprint linenums"><code>my-app
|-- pom.xml
@@ -644,7 +644,7 @@ InputStream is = getClass().getResourceA
</project>
</code></pre></div>
<p>You'll notice that we had to add the <code>build</code>,
<code>resources</code>, and <code>resource</code> elements which weren't there
before. In addition, we had to explicitly state that the resources are located
in the src/main/resources directory. All of this information was provided as
default values previously, but because the default value for
<code>filtering</code> is false, we had to add this to our pom.xml in order to
override that default value and set <code>filtering</code> to true.</p>
-<p>To reference a property defined in your pom.xml, the property name uses the
names of the XML elements that define the value, with “pom” being
allowed as an alias for the project (root) element. So
<code>$\{project.name\}</code> refers to the name of the project,
<code>$\{project.version\}</code> refers to the version of the project,
<code>$\{project.build.finalName\}</code> refers to the final name of the file
created when the built project is packaged, etc. Note that some elements of the
POM have default values, so don't need to be explicitly defined in your
<code>pom.xml</code> for the values to be available here. Similarly, values in
the user's <code>settings.xml</code> can be referenced using property names
beginning with “settings” (for example,
<code>$\{settings.localRepository\}</code> refers to the path of the user's
local repository).</p>
+<p>To reference a property defined in your pom.xml, the property name uses the
names of the XML elements that define the value, with “pom” being
allowed as an alias for the project (root) element. So
<code>${project.name}</code> refers to the name of the project,
<code>${project.version}</code> refers to the version of the project,
<code>${project.build.finalName}</code> refers to the final name of the file
created when the built project is packaged, etc. Note that some elements of the
POM have default values, so don't need to be explicitly defined in your
<code>pom.xml</code> for the values to be available here. Similarly, values in
the user's <code>settings.xml</code> can be referenced using property names
beginning with “settings” (for example,
<code>${settings.localRepository}</code> refers to the path of the user's local
repository).</p>
<p>To continue our example, let's add a couple of properties to the
<code>application.properties</code> file (which we put in the
<code>src/main/resources</code> directory) whose values will be supplied when
the resource is filtered:</p>
<div class="source"><pre class="prettyprint linenums"><code>#
application.properties
@@ -785,7 +785,7 @@ command.line.prop=${command.line.prop}
<p>For each external dependency, you'll need to define at least 4 things:
groupId, artifactId, version, and scope. The groupId, artifactId, and version
are the same as those given in the <code>pom.xml</code> for the project that
built that dependency. The scope element indicates how your project uses that
dependency, and can be values like <code>compile</code>, <code>test</code>, and
<code>runtime</code>. For more information on everything you can specify for a
dependency, see the <a href="/ref/current/maven-model/maven.html">Project
Descriptor Reference</a>.</p><!-- DJ: Does this link work? I can't find the
document. -->
<p>For more information about the dependency mechanism as a whole, see <a
href="../introduction/introduction-to-dependency-mechanism.html">Introduction
to Dependency Mechanism</a>.</p>
-<p>With this information about a dependency, Maven will be able to reference
the dependency when it builds the project. Where does Maven reference the
dependency from? Maven looks in your local repository
(<code>$\{user.home\}/.m2/repository</code> is the default location) to find
all dependencies. In a <a
href="How_do_I_create_a_JAR_and_install_it_in_my_local_repository">previous
section</a>, we installed the artifact from our project
(my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed there,
another project can reference that jar as a dependency simply by adding the
dependency information to its pom.xml:</p>
+<p>With this information about a dependency, Maven will be able to reference
the dependency when it builds the project. Where does Maven reference the
dependency from? Maven looks in your local repository
(<code>${user.home}/.m2/repository</code> is the default location) to find all
dependencies. In a <a
href="How_do_I_create_a_JAR_and_install_it_in_my_local_repository">previous
section</a>, we installed the artifact from our project
(my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed there,
another project can reference that jar as a dependency simply by adding the
dependency information to its pom.xml:</p>
<div class="source"><pre class="prettyprint linenums"><code><project
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd">
Modified:
maven/website/content/guides/getting-started/windows-prerequisites.html
==============================================================================
--- maven/website/content/guides/getting-started/windows-prerequisites.html
(original)
+++ maven/website/content/guides/getting-started/windows-prerequisites.html Thu
Feb 9 23:13:59 2023
@@ -152,9 +152,9 @@ under the License.
</code></pre></div>
<p>must show the right version number.</p></section><section>
<h3>Maven Unpacked</h3>
-<p>You need to unpack the Maven distribution. Don't unpack it in the middle of
your source code; pick some location and unpack it there. Let's assume that the
path is <code>$\{maven.home\}</code>.</p></section><section>
+<p>You need to unpack the Maven distribution. Don't unpack it in the middle of
your source code; pick some location and unpack it there. Let's assume that the
path is <code>${maven.home}</code>.</p></section><section>
<h3>Maven in PATH</h3>
-<p>You run Maven by invoking a command-line tool: <code>mvn.cmd</code> from
the <code>bin</code> directory of the Maven. To do this conveniently,
<code>$\{maven.home\}\\bin</code> must be in your PATH, just like the Java SDK
commands. You can add directories to your <code>PATH</code> in the control
panel; the details vary by Windows version.</p></section><section>
+<p>You run Maven by invoking a command-line tool: <code>mvn.cmd</code> from
the <code>bin</code> directory of the Maven. To do this conveniently,
<code>${maven.home}/bin</code> must be in your PATH, just like the Java SDK
commands. You can add directories to your <code>PATH</code> in the control
panel; the details vary by Windows version.</p></section><section>
<h3>Firewalls and Anti-virus</h3>
<p>Firewall and Anti-virus sometimes prevent Java from running properly, or
Windows Firewall (and various other Firewalls) actively prevent Java.exe from
reaching out to the Internet to “download stuff” which is a key
part of Maven. You may need to configure the Firewall or Anti-virus to add
exceptions to allow such actions.</p></section></section></section>
</main>
Modified:
maven/website/content/guides/introduction/introduction-to-plugin-prefix-mapping.html
==============================================================================
---
maven/website/content/guides/introduction/introduction-to-plugin-prefix-mapping.html
(original)
+++
maven/website/content/guides/introduction/introduction-to-plugin-prefix-mapping.html
Thu Feb 9 23:13:59 2023
@@ -169,9 +169,9 @@ under the License.
<ul>
<li>
-<p><code>maven-$\{prefix\}-plugin</code> - for official plugins maintained by
the Apache Maven team itself (you <strong>must not</strong> use this naming
pattern for your plugin, see <a
href="../plugin/guide-java-plugin-development.html#Plugin_Naming_Convention_and_Apache_Maven_Trademark">this
note for more informations</a>)</p></li>
+<p><code>maven-${prefix}-plugin</code> - for official plugins maintained by
the Apache Maven team itself (you <strong>must not</strong> use this naming
pattern for your plugin, see <a
href="../plugin/guide-java-plugin-development.html#Plugin_Naming_Convention_and_Apache_Maven_Trademark">this
note for more informations</a>)</p></li>
<li>
-<p><code>$\{prefix\}-maven-plugin</code> - for plugins from other
sources</p></li>
+<p><code>${prefix}-maven-plugin</code> - for plugins from other
sources</p></li>
</ul>
<p>If your plugin's artifactId fits this pattern, Maven will automatically map
your plugin to the correct prefix in the metadata stored within your plugin's
groupId path on the repository. However, if you want to customize the prefix
used to reference your plugin, you can specify the prefix directly through a
configuration parameter on the <code>maven-plugin-plugin</code> in your
plugin's POM:</p>
@@ -199,13 +199,13 @@ under the License.
</code></pre></div></section><section>
<h3>Mapping Prefixes to Plugins</h3>
<p>For each groupId configured for searching, Maven will:</p>
-<p>1 Download <code>maven-metadata.xml</code> from each remote repository into
the local repository, and name it <code>maven-metadata-$\{repoId\}.xml</code>
within the path of ${groupId}.</p>
-<p>1 Load these metadata files, along with
<code>maven-metadata-local.xml</code> (if it exists), within the path of
${groupId}. Merge them.</p>
+<p>1 Download <code>maven-metadata.xml</code> from each remote repository into
the local repository, and name it <code>maven-metadata-${repoId}.xml</code>
within the path of <code>${groupId}</code>.</p>
+<p>1 Load these metadata files, along with
<code>maven-metadata-local.xml</code> (if it exists), within the path of
<code>${groupId}</code>. Merge them.</p>
<p>1 Lookup the plugin prefix in the merged metadata. If it's mapped, it
should refer to a concrete groupId-artifactId pair. Otherwise, go on to #1 for
the next groupId in the user's plugin-groups.</p>
<p>These metadata files consist of the <strong>groupId</strong> it represents
(for clarity when the file is opened outside the context of the directory), and
a group of <strong>plugin</strong> elements. Each <strong>plugin</strong> in
this list contains a <strong>prefix</strong> element denoting the plugin's
command-line prefix, and an <strong>artifactId</strong> element, which provides
the other side of the prefix mapping and provides enough information to lookup
and use the plugin. When a plugin is installed or deployed, the appropriate
metadata file is located - and if the prefix mapping is missing - modified to
include the plugin-prefix mapping.</p></section><section>
<h3>Configuring Maven to Search for Plugins</h3>
<p>By default, Maven will search the groupId
<strong>org.apache.maven.plugins</strong> for prefix-to-artifactId mappings for
the plugins it needs to perform a given build. However, as previously
mentioned, the user may have a need for third-party plugins. Since the Maven
project is assumed to have control over the default plugin groupId, this means
configuring Maven to search other groupId locations for plugin-prefix
mappings.</p>
-<p>As it turns out, this is simple. In the Maven settings file (per-user:
<code>$\{user.home\}/.m2/settings.xml</code>; global:
<code>$\{maven.home\}/conf/settings.xml</code>), you can provide a custom
<strong>pluginGroups</strong> section, listing the plugin groupIds you want to
search (each groupId goes in its own <strong>pluginGroup</strong> sub-element).
For example, if my project uses a Modello model file, I might have the
following in my settings:</p>
+<p>As it turns out, this is simple. In the Maven settings file (per-user:
<code>${user.home}/.m2/settings.xml</code>; global:
<code>${maven.home}/conf/settings.xml</code>), you can provide a custom
<strong>pluginGroups</strong> section, listing the plugin groupIds you want to
search (each groupId goes in its own <strong>pluginGroup</strong> sub-element).
For example, if my project uses a Modello model file, I might have the
following in my settings:</p>
<div class="source"><pre class="prettyprint
linenums"><code><pluginGroups>
<pluginGroup>org.codehaus.modello</pluginGroup>
Modified: maven/website/content/guides/introduction/introduction-to-plugins.html
==============================================================================
--- maven/website/content/guides/introduction/introduction-to-plugins.html
(original)
+++ maven/website/content/guides/introduction/introduction-to-plugins.html Thu
Feb 9 23:13:59 2023
@@ -160,7 +160,7 @@ under the License.
<h3>What is a Plugin?</h3>
<p>“Maven” is really just a core framework for a collection of
Maven Plugins. In other words, plugins are where much of the real action is
performed, plugins are used to: create jar files, create war files, compile
code, unit test code, create project documentation, and on and on. Almost any
action that you can think of performing on a project is implemented as a Maven
plugin.</p>
<p>Plugins are the central feature of Maven that allow for the reuse of common
build logic across multiple projects. They do this by executing an
“action” (i.e. creating a WAR file or compiling unit tests) in
the context of a project's description - the Project Object Model (POM). Plugin
behavior can be customized through a set of unique parameters which are exposed
by a description of each plugin goal (or Mojo).</p>
-<p>One of the simplest plugins in Maven is the Clean Plugin. The <a
href="../../plugins/maven-clean-plugin/">Maven Clean plugin</a>
(maven-clean-plugin) is responsible for removing the target directory of a
Maven project. When you run “mvn clean”, Maven executes the
“clean” goal as defined in the Clean plug-in, and the target
directory is removed. The Clean plugin <a
href="../../plugins/maven-clean-plugin/clean-mojo.html">defines a parameter</a>
which can be used to customize plugin behavior, this parameter is called
outputDirectory and it defaults to
${project.build.directory}.</p></section><section>
+<p>One of the simplest plugins in Maven is the Clean Plugin. The <a
href="../../plugins/maven-clean-plugin/">Maven Clean plugin</a>
(maven-clean-plugin) is responsible for removing the target directory of a
Maven project. When you run “mvn clean”, Maven executes the
“clean” goal as defined in the Clean plug-in, and the target
directory is removed. The Clean plugin <a
href="../../plugins/maven-clean-plugin/clean-mojo.html">defines a parameter</a>
which can be used to customize plugin behavior, this parameter is called
outputDirectory and it defaults to
<code>${project.build.directory}</code>.</p></section><section>
<h3>What is a Mojo (<em>And Why the H— is it Named
‘Mojo’</em>)?</h3>
<p>A Mojo is really just a <strong>goal</strong> in Maven, and plug-ins
consist of any number of goals (Mojos). Mojos can be defined as annotated Java
classes or Beanshell script. A Mojo specifies metadata about a goal: a goal
name, which phase of the lifecycle it fits into, and the parameters it is
expecting.</p>
<p>MOJO is a play on POJO (Plain-old-Java-object), substituting
“Maven” for “Plain”. Mojo is also an interesting
word (see <a href="http://www.answers.com/mojo&r=67"
class="externalLink">definition</a>). From <a href="http://www.wikipedia.org"
class="externalLink">Wikipedia</a>, a “mojo” is defined as:
“…a small bag worn by a person under the clothes (also known as a
mojo hand). Such bags were thought to have supernatural powers, such as
protecting from evil, bringing good luck, etc.”</p></section><section>
Modified:
maven/website/content/guides/introduction/introduction-to-profiles.html
==============================================================================
--- maven/website/content/guides/introduction/introduction-to-profiles.html
(original)
+++ maven/website/content/guides/introduction/introduction-to-profiles.html Thu
Feb 9 23:13:59 2023
@@ -230,7 +230,7 @@ under the License.
<p>Global</p>
<ul>
-<li>Defined in the <a href="/ref/current/maven-settings/settings.html">global
Maven-settings</a> <code>($\{maven.home\}/conf/settings.xml)</code>.</li>
+<li>Defined in the <a href="/ref/current/maven-settings/settings.html">global
Maven-settings</a> <code>(${maven.home}/conf/settings.xml)</code>.</li>
</ul></li>
<li>
<p>Profile descriptor</p>
@@ -551,7 +551,7 @@ mvn groupId:artifactId:goal -Ddebug=fals
...
</project>
</code></pre></div>
-<p>Now, in your local <code>$\{user.home\}/.m2/settings.xml</code>, you
have:</p>
+<p>Now, in your local <code>${user.home}/.m2/settings.xml</code>, you have:</p>
<div class="source"><pre class="prettyprint linenums"><code><settings>
...
@@ -641,7 +641,7 @@ mvn groupId:artifactId:goal -Ddebug=fals
<div class="source"><pre class="prettyprint linenums"><code>mvn
-Denv=production integration-test
</code></pre></div>
-<p>will not do a successful build. Why? Because, the resulting
non-interpolated literal value of <code>$\{appserver.home\}</code> will not be
a valid path for deploying and testing your web application. We haven't
considered the case for the production environment when writing our profiles.
The “production” environment (env=production), along with
“test” and possibly even “local” constitute a
natural set of target environments for which we may want to build the
integration-test lifecycle phase. The incomplete specification of this natural
set means we have effectively limited our valid target environments to the
development environment. Your teammates - and probably your manager - will not
see the humor in this. When you construct profiles to handle cases such as
these, be sure to address the entire set of target permutations.</p>
+<p>will not do a successful build. Why? Because, the resulting
non-interpolated literal value of <code>${appserver.home}</code> will not be a
valid path for deploying and testing your web application. We haven't
considered the case for the production environment when writing our profiles.
The “production” environment (env=production), along with
“test” and possibly even “local” constitute a
natural set of target environments for which we may want to build the
integration-test lifecycle phase. The incomplete specification of this natural
set means we have effectively limited our valid target environments to the
development environment. Your teammates - and probably your manager - will not
see the humor in this. When you construct profiles to handle cases such as
these, be sure to address the entire set of target permutations.</p>
<p>As a quick aside, it's possible for user-specific profiles to act in a
similar way. This means that profiles for handling different environments which
are keyed to the user can act up when the team adds a new developer. While I
suppose this <em>could</em> act as useful training for the newbie, it just
wouldn't be nice to throw them to the wolves in this way. Again, be sure to
think of the <em>whole</em> set of profiles.</p></section></section><section>
<h3>How can I tell which profiles are in effect during a build?</h3>
<p>Determining active profiles will help the user to know what particular
profiles has been executed during a build. We can use the <a
href="/plugins/maven-help-plugin/">Maven Help Plugin</a> to tell what profiles
are in effect during a build.</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 Thu
Feb 9 23:13:59 2023
@@ -507,7 +507,7 @@ under the License.
<p>One factor to note is that these variables are processed <em>after</em>
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>Available Variables</h4><section>
<h5>Project Model Variables</h5>
-<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>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
“<code>project.</code>”. 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>Special Variables</h5>
<table class="table table-striped">
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 Thu Feb
9 23:13:59 2023
@@ -174,7 +174,7 @@ under the License.
<h2>Guide to deploying 3rd party JARs to remote repository</h2>
<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>
+<p>First, the wagon-provider(wagon-ftp, wagon-file, etc..) must be placed to
your <code>${maven.home}/lib</code>.</p>
<p>Then execute the command:</p>
<div class="source"><pre class="prettyprint linenums"><code>mvn
deploy:deploy-file -DgroupId=<group-id> \
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 Thu Feb 9 23:13:59
2023
@@ -212,7 +212,7 @@ under the License.
...
</project>
</code></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>
+<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>Creating a binary assembly</h3>
<p>This is the most typical usage of the assembly plugin where you are
creating a distribution for standard use.</p>
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 Thu Feb 9
23:13:59 2023
@@ -143,7 +143,7 @@ under the License.
-->
<section><section>
<h2>Guide to using attached tests</h2>
-<p>You can reuse the tests that you have created for one project in another.
For example, suppose <code>foo-core</code> contains test code in the
<code>$\{basedir\}/src/test/java</code>. To package up those compiled tests in
a JAR and deploy them for general reuse, configure the
<code>maven-jar-plugin</code> as follows:</p>
+<p>You can reuse the tests that you have created for one project in another.
For example, suppose <code>foo-core</code> contains test code in the
<code>${basedir}/src/test/java</code>. To package up those compiled tests in a
JAR and deploy them for general reuse, configure the
<code>maven-jar-plugin</code> as follows:</p>
<div class="source"><pre class="prettyprint linenums"><code>
<project>
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 Thu Feb 9
23:13:59 2023
@@ -188,9 +188,9 @@ under the License.
<p><strong>Note:</strong> the installation and user configuration cannot be
used to add shared project information - for example, setting
<code><organization></code> or
<code><distributionManagement></code> company-wide.</p>
<p>For this, you should have your projects inherit from a company-wide parent
<code>pom.xml</code>.</p><!-- TODO: versioning doc that discusses this -->
-<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>
+<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>Configuring your Local Repository</h3>
-<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>
+<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"><code><settings>
...
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
23:13:59 2023
@@ -254,7 +254,7 @@ archetype
</code></pre></div></section><section>
<h3>3. Create the prototype files and the prototype pom.xml</h3>
-<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>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"><code>
Modified: maven/website/content/guides/mini/guide-encryption.html
==============================================================================
--- maven/website/content/guides/mini/guide-encryption.html (original)
+++ maven/website/content/guides/mini/guide-encryption.html Thu Feb 9 23:13:59
2023
@@ -194,7 +194,7 @@ under the License.
<ul>
<li>
-<p>authorized users have an additional <code>settings-security.xml</code> file
in their <code>$\{user.home\}/.m2</code> folder</p></li>
+<p>authorized users have an additional <code>settings-security.xml</code> file
in their <code>${user.home}/.m2</code> folder</p></li>
<li>
<p>this file either contains encrypted <strong>master password</strong>, used
to encrypt other passwords</p></li>
<li>
@@ -216,7 +216,7 @@ under the License.
<div class="source"><pre class="prettyprint
linenums"><code>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}
</code></pre></div>
-<p>Store this password in the
<code>$\{user.home\}/.m2/settings-security.xml</code>; it should look like</p>
+<p>Store this password in the
<code>${user.home}/.m2/settings-security.xml</code>; it should look like</p>
<div class="source"><pre class="prettyprint
linenums"><code><settingsSecurity>
<master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master>
@@ -279,7 +279,7 @@ under the License.
</settingsSecurity>
</code></pre></div>
<p>in the file
<code>/Volumes/mySecureUsb/secure/settings-security.xml</code></p>
-<p>And then I create <code>$\{user.home\}/.m2/settings-security.xml</code>
with the following content:</p>
+<p>And then I create <code>${user.home}/.m2/settings-security.xml</code> with
the following content:</p>
<div class="source"><pre class="prettyprint
linenums"><code><settingsSecurity>
<relocation>/Volumes/mySecureUsb/secure/settings-security.xml</relocation>
@@ -295,7 +295,7 @@ under the License.
</code></pre></div>
<p>Then, the value you would add to your settings.xml looks like this:</p>
-<div class="source"><pre class="prettyprint
linenums"><code>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+\{EF1iFQyJQ=}
+<div class="source"><pre class="prettyprint
linenums"><code>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+{EF1iFQyJQ=}
</code></pre></div></section><section>
<h4>Password Security</h4>
<p>Editing <code>settings.xml</code> and running the above commands can still
leave your password stored locally in plaintext. You may want to check the
following locations:</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
23:13:59 2023
@@ -197,7 +197,7 @@ under the License.
<p><a href="Custom_Classloaders">Custom Classloaders</a></p></li>
</ul><section>
<h3>Overview</h3>
-<p>Maven uses the <a
href="https://codehaus-plexus.github.io/plexus-classworlds/"
class="externalLink">Plexus Classworlds</a> classloading framework to create
the classloader graph. If you look in your <code>$\{maven.home\}/boot</code>
directory, you will see a single JAR which is the Classworlds JAR we use to
boot the classloader graph. The Classworlds JAR is the only element of the Java
<code>CLASSPATH</code>. The other classloaders are built by Classworlds
(“realms” in Classworlds terminology).</p>
+<p>Maven uses the <a
href="https://codehaus-plexus.github.io/plexus-classworlds/"
class="externalLink">Plexus Classworlds</a> classloading framework to create
the classloader graph. If you look in your <code>${maven.home}/boot</code>
directory, you will see a single JAR which is the Classworlds JAR we use to
boot the classloader graph. The Classworlds JAR is the only element of the Java
<code>CLASSPATH</code>. The other classloaders are built by Classworlds
(“realms” in Classworlds terminology).</p>
<p>Each realm exposes</p>
<p>1 optionally some classes imported from 0..n other classloaders</p>
<p>1 optionally some classes from a directory or JAR</p>
@@ -208,8 +208,8 @@ under the License.
<h3>System Classloader</h3>
<p>It contains only Plexus Classworlds and imports the platform
classloader.</p></section><section>
<h3>Core Classloader</h3>
-<p>The second classloader down the graph contains the core requirements of
Maven. <strong>It is used by Maven internally but not by plugins</strong>. The
core classloader has the libraries in <code>$\{maven.home\}/lib</code>. In
general these are just Maven libraries. For example instances of
<code>[MavenProject](/ref/current/apidocs/org/apache/maven/project/MavenProject.html)</code>
belong to this classloader.</p>
-<p>You can add elements to this classloader by <a
href="/ref/current/maven-model/maven.html#class_extension">extensions</a>.
These are loaded through the same classloader as
<code>$\{maven.home\}/lib</code> and hence are available to the Maven core and
all plugins for the current project (through the API classloader). More
information is available in <a href="./guide-using-extensions.html">Core
Extension</a>.</p></section><section>
+<p>The second classloader down the graph contains the core requirements of
Maven. <strong>It is used by Maven internally but not by plugins</strong>. The
core classloader has the libraries in <code>${maven.home}/lib</code>. In
general these are just Maven libraries. For example instances of
<code>[MavenProject](/ref/current/apidocs/org/apache/maven/project/MavenProject.html)</code>
belong to this classloader.</p>
+<p>You can add elements to this classloader by <a
href="/ref/current/maven-model/maven.html#class_extension">extensions</a>.
These are loaded through the same classloader as <code>${maven.home}/lib</code>
and hence are available to the Maven core and all plugins for the current
project (through the API classloader). More information is available in <a
href="./guide-using-extensions.html">Core Extension</a>.</p></section><section>
<h3>API Classloader</h3>
<p>The API classloader is filtered view of the Core Classloader by exposing
only the exported packages from all Core Extensions. The main API is listed in
<a href="https://maven.apache.org/ref/3-LATEST/maven-core/core-extensions.html"
class="externalLink">Maven Core Extensions Reference</a>.</p>
<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>
@@ -238,7 +238,7 @@ under the License.
...
</plugin>
</code></pre></div>
-<p>Plugins can inspect their effective runtime class path via the expressions
<code>$\{plugin.artifacts\}</code> or <code>$\{plugin.artifactMap\}</code> to
have a list or map, respectively, of resolved artifacts injected from the
<code>[PluginDescriptor](/ref/current/maven-plugin-api/apidocs/org/apache/maven/plugin/descriptor/PluginDescriptor.html)</code>.</p>
+<p>Plugins can inspect their effective runtime class path via the expressions
<code>${plugin.artifacts}</code> or <code>${plugin.artifactMap}</code> to have
a list or map, respectively, of resolved artifacts injected from the
<code>[PluginDescriptor](/ref/current/maven-plugin-api/apidocs/org/apache/maven/plugin/descriptor/PluginDescriptor.html)</code>.</p>
<p>Please note that the plugin classloader does neither contain the <a
href="/ref/current/maven-model/maven.html#class_dependency">dependencies</a> of
the current project nor its build output. Instead, plugins can query the
project's compile, runtime and test class path from the
<code>[MavenProject](/ref/current/apidocs/org/apache/maven/project/MavenProject.html)</code>
in combination with the mojo annotation
<code>requiresDependencyResolution</code> from the <a
href="/developers/mojo-api-specification.html">Mojo API Specification</a>. For
instance, flagging a mojo with <code>@requiresDependencyResolution
runtime</code> enables it to query the runtime class path of the current
project from which it could create further classloaders.</p>
<p>When a build plugin is executed, the thread's context classloader is set to
the plugin classloader.</p></section><section>
<h3>Custom Classloaders</h3>
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
23:13:59 2023
@@ -183,7 +183,7 @@ under the License.
<li>
<p>You want to run a <a href="../../repository-management.html">repository
manager</a> to provide a local cache to a mirror and need to use its URL
instead</p></li>
</ul>
-<p>To configure a mirror of a given repository, you provide it in your
settings file (<code>$\{user.home\}/.m2/settings.xml</code>), giving the new
repository its own <code>id</code> and <code>url</code>, and specify the
<code>mirrorOf</code> setting that is the ID of the repository you are using a
mirror of. For example, the ID of the main Maven Central repository included by
default is <code>central</code>, so to use the different mirror instance, you
would configure the following:</p>
+<p>To configure a mirror of a given repository, you provide it in your
settings file (<code>${user.home}/.m2/settings.xml</code>), giving the new
repository its own <code>id</code> and <code>url</code>, and specify the
<code>mirrorOf</code> setting that is the ID of the repository you are using a
mirror of. For example, the ID of the main Maven Central repository included by
default is <code>central</code>, so to use the different mirror instance, you
would configure the following:</p>
<div class="source"><pre class="prettyprint linenums"><code><settings>
...
Modified: maven/website/content/guides/mini/guide-multiple-repositories.html
==============================================================================
--- maven/website/content/guides/mini/guide-multiple-repositories.html
(original)
+++ maven/website/content/guides/mini/guide-multiple-repositories.html Thu Feb
9 23:13:59 2023
@@ -194,7 +194,7 @@ under the License.
</code></pre></div>
<p><strong>NOTE:</strong> You will also get the standard set of repositories
as defined in the <a
href="../introduction/introduction-to-the-pom.html#Super_POM">Super POM</a>.</p>
-<p>The other way you can specify multiple repositories is by creating a
profile in the <code>$\{user.home\}/.m2/settings.xml</code> or
<code>$\{maven.home\}/conf/settings.xml</code> file like the following:</p>
+<p>The other way you can specify multiple repositories is by creating a
profile in the <code>${user.home}/.m2/settings.xml</code> or
<code>${maven.home}/conf/settings.xml</code> file like the following:</p>
<div class="source"><pre class="prettyprint linenums"><code>
<settings>
Modified: maven/website/content/guides/mini/guide-proxies.html
==============================================================================
--- maven/website/content/guides/mini/guide-proxies.html (original)
+++ maven/website/content/guides/mini/guide-proxies.html Thu Feb 9 23:13:59
2023
@@ -172,7 +172,7 @@ under the License.
-->
<section><section>
<h2>Configuring a proxy</h2>
-<p>You can configure a proxy to use for some or all of your HTTP requests with
Maven. The username and password are only required if your proxy requires basic
authentication (note that later releases may support storing your passwords in
a secured keystore - in the mean time, please ensure your settings.xml file
(usually ${user.home}/.m2/settings.xml) is secured with permissions appropriate
for your operating system).</p>
+<p>You can configure a proxy to use for some or all of your HTTP requests with
Maven. The username and password are only required if your proxy requires basic
authentication (note that later releases may support storing your passwords in
a secured keystore - in the mean time, please ensure your settings.xml file
(usually <code>${user.home}/.m2/settings.xml</code>) is secured with
permissions appropriate for your operating system).</p>
<p>The <code>nonProxyHosts</code> setting accepts wild cards, and each host
not to proxy is separated by the | character. This matches the JDK
configuration equivalent.</p>
<div class="source"><pre class="prettyprint linenums"><code>
Modified: maven/website/content/guides/mini/guide-reproducible-builds.html
==============================================================================
--- maven/website/content/guides/mini/guide-reproducible-builds.html (original)
+++ maven/website/content/guides/mini/guide-reproducible-builds.html Thu Feb 9
23:13:59 2023
@@ -229,7 +229,7 @@ under the License.
<li>
<p>if you have a custom release process tooling, you'll need to add the
feature to your release tooling. Notice that if you're using
<code>versions-maven-plugin</code> in custom release scripts, starting with
release 2.9.0, <a
href="https://github.com/mojohaus/versions-maven-plugin/issues/453"
class="externalLink"><code>versions:set</code> goal updates the
property</a>.</p></li>
<li>
-<p>instead of explicitely writing a timestamp in their <code>pom.xml</code>,
some people tend to prefer using last Git commit timestamp, like
<code>$\{git.commit.time\}</code> from <a
href="https://github.com/git-commit-id/git-commit-id-maven-plugin"
class="externalLink">git-commit-id-maven-plugin</a>.</p></li>
+<p>instead of explicitely writing a timestamp in their <code>pom.xml</code>,
some people tend to prefer using last Git commit timestamp, like
<code>${git.commit.time}</code> from <a
href="https://github.com/git-commit-id/git-commit-id-maven-plugin"
class="externalLink">git-commit-id-maven-plugin</a>.</p></li>
</ul>
<p>Don't hesitate to share your questions or solutions on <a
href="/mailing-lists.html">user mailing-list</a>.</p>
<ul>
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 23:13:59 2023
@@ -181,7 +181,7 @@ under the License.
|
+- site.xml
</code></pre></div>
-<p>You will notice there is now a <code>$\{basedir\}/src/site</code> directory
within which is contained a <code>site.xml</code> site descriptor along with
various directories corresponding to the supported document types.</p>
+<p>You will notice there is now a <code>${basedir}/src/site</code> directory
within which is contained a <code>site.xml</code> site descriptor along with
various directories corresponding to the supported document types.</p>
<p>Let's take a look at the examples of the various document types:</p>
<ul>
Modified: maven/website/content/guides/mini/guide-snippet-macro.html
==============================================================================
--- maven/website/content/guides/mini/guide-snippet-macro.html (original)
+++ maven/website/content/guides/mini/guide-snippet-macro.html Thu Feb 9
23:13:59 2023
@@ -206,7 +206,7 @@ under the License.
%{snippet|id=snip-id|url=file:///path/to/Sample.java}
</code></pre></div>
-<p>As of doxia-core version 1.0-alpha-9, a ‘file’ parameter is
also available. If a full path is not specified, the location is assumed to be
relative to ${basedir}.</p>
+<p>As of doxia-core version 1.0-alpha-9, a ‘file’ parameter is
also available. If a full path is not specified, the location is assumed to be
relative to <code>${basedir}</code>.</p>
<div class="source"><pre class="prettyprint linenums"><code> ~~ Since
doxia-core 1.0-alpha-9
%{snippet|id=abc|file=src/main/webapp/index.jsp}
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
23:13:59 2023
@@ -183,7 +183,7 @@ under the License.
<ul>
<li>
-<p>Registered via extension jar in
<code>$\{maven.home\}/lib/ext</code></p></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>
<li>
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
23:13:59 2023
@@ -283,7 +283,7 @@ under the License.
</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 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>
+<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"?>
<toolchains>
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 23:13:59 2023
@@ -342,9 +342,9 @@ public class GreetingMojo extends Abstra
<li>
<p>If you need to run the latest version of a plugin installed in your local
repository, you can omit its version number. So just use “<code>mvn
sample.plugin:hello-maven-plugin:sayhi</code>” to run your
plugin.</p></li>
<li>
-<p>You can assign a shortened prefix to your plugin, such as <code>mvn
hello:sayhi</code>. This is done automatically if you follow the convention of
using <code>$\{prefix\}-maven-plugin</code> (or
<code>maven-$\{prefix\}-plugin</code> if the plugin is part of the Apache Maven
project). You may also assign one through additional configuration - for more
information see <a
href="../introduction/introduction-to-plugin-prefix-mapping.html">Introduction
to Plugin Prefix Mapping</a>.</p></li>
+<p>You can assign a shortened prefix to your plugin, such as <code>mvn
hello:sayhi</code>. This is done automatically if you follow the convention of
using <code>${prefix}-maven-plugin</code> (or
<code>maven-${prefix}-plugin</code> if the plugin is part of the Apache Maven
project). You may also assign one through additional configuration - for more
information see <a
href="../introduction/introduction-to-plugin-prefix-mapping.html">Introduction
to Plugin Prefix Mapping</a>.</p></li>
<li>
-<p>Finally, you can also add your plugin's groupId to the list of groupIds
searched by default. To do this, you need to add the following to your
<code>$\{user.home\}/.m2/settings.xml</code> file:</p></li>
+<p>Finally, you can also add your plugin's groupId to the list of groupIds
searched by default. To do this, you need to add the following to your
<code>${user.home}/.m2/settings.xml</code> file:</p></li>
</ul>
<div class="source"><pre class="prettyprint
linenums"><code><pluginGroups>
@@ -409,7 +409,7 @@ public class GreetingMojo extends Abstra
@Parameter( property = "sayhi.greeting", defaultValue =
"Hello World!" )
private String greeting;
</code></pre></div>
-<p>The portion before the annotations is the description of the parameter. The
<code>parameter</code> annotation identifies the variable as a mojo parameter.
The <code>defaultValue</code> parameter of the annotation defines the default
value for the variable. This value can include expressions which reference the
project, such as “<code>$\{project.version\}</code>” (more can be
found in the <a
href="/ref/current/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html">“Parameter
Expressions” document</a>). The <code>property</code> parameter can be
used to allow configuration of the mojo parameter from the command line by
referencing a system property that the user sets via the <code>-D</code>
option.</p></section><section>
+<p>The portion before the annotations is the description of the parameter. The
<code>parameter</code> annotation identifies the variable as a mojo parameter.
The <code>defaultValue</code> parameter of the annotation defines the default
value for the variable. This value can include expressions which reference the
project, such as “<code>${project.version}</code>” (more can be
found in the <a
href="/ref/current/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html">“Parameter
Expressions” document</a>). The <code>property</code> parameter can be
used to allow configuration of the mojo parameter from the command line by
referencing a system property that the user sets via the <code>-D</code>
option.</p></section><section>
<h4>Configuring Parameters in a Project</h4>
<p>Configuring the parameter values for a plugin is done in a Maven project
within the <code>pom.xml</code> file as part of defining the plugin in the
project. An example of configuring a plugin:</p>
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
23:13:59 2023
@@ -307,7 +307,7 @@ if ( "info".equals( debugLevel
<p>The problem is that the JVM executing Maven can be running much longer than
the actual Maven build. Of course, this does not apply to the standalone
invocation of Maven from the command line. However, it affects the embedded
usage of Maven in IDEs or CI servers. In those cases, the cleanup tasks will be
deferred, too. If the JVM is then executing a bunch of other Maven builds, many
such cleanup tasks can sum up, eating up resources of the JVM.</p>
<p>For this reason, plugin developers should avoid usage of shutdown hooks and
rather use <code>try</code>/<code>finally</code> blocks to perform cleanup as
soon as the resources are no longer needed.</p></section><section>
<h3>Resolving Relative Paths</h3>
-<p>It is common practice for users of Maven to specify relative paths in the
POM, not to mention that the Super POM does so, too. The intention is to
resolve such relative paths against the base directory of the current project.
In other words, the paths <code>target/classes</code> and
<code>$\{basedir\}/target/classes</code> should resolve to the same directory
for a given POM.</p>
+<p>It is common practice for users of Maven to specify relative paths in the
POM, not to mention that the Super POM does so, too. The intention is to
resolve such relative paths against the base directory of the current project.
In other words, the paths <code>target/classes</code> and
<code>${basedir}/target/classes</code> should resolve to the same directory for
a given POM.</p>
<p>Unfortunately, the class
<code>[java.io.File](http://java.sun.com/javase/6/docs/api/java/io/File.html)</code>
does not resolve relative paths against the project's base directory. As
mentioned in its class javadoc, it resolves relative paths against the current
working directory. In plain English: Unless a Maven component has complete
control over the current working directory, any usage of
<code>java.io.File</code> in combination with a relative path is a bug.</p>
<p>At first glance, one might be tempted to argue that the project base
directory is equal to the current working directory. However, this assumption
is generally not true. Consider the following scenarios:</p>
<p>a Reactor Builds</p>
@@ -346,7 +346,7 @@ if ( !file.isAbsolute() )
<p>Many Maven plugins can get this resolution automatically if they declare
their affected mojo parameters of type <code>java.io.File</code> instead of
<code>java.lang.String</code>. This subtle difference in parameter types will
trigger a feature known as <em>path translation</em>, i.e. the Maven core will
automatically resolve relative paths when it pumps the XML configuration into a
mojo.</p></section><section>
<h3>Determining the Output Directory for a Site Report</h3>
<p>Most reporting plugins inherit from <code>AbstractMavenReport</code>. In
doing so, they need to implement the inherited but abstract method
<code>getOutputDirectory()</code>. To implement this method, plugins usually
declare a field named <code>outputDirectory</code> which they return in the
method. Nothing wrong so far.</p>
-<p>Now, some plugins need to create additional files in the report output
directory that accompany the report generated via the sink interface. While it
is tempting to use either the method <code>getOutputDirectory()</code> or the
field <code>outputDirectory</code> directly in order to setup a path for the
output files, this leads most likely to a bug. More precisely, those plugins
will not properly output files when run by the Maven Site Plugin as part of the
site lifecycle. This is best noticed when the output directory for the site is
configured directly in the Maven Site Plugin such that it deviates from the
expression <code>$\{project.reporting.outputDirectory\}</code> that the plugins
use by default. Multi-language site generation is another scenario to exploit
this bug which is illustrated below:</p>
+<p>Now, some plugins need to create additional files in the report output
directory that accompany the report generated via the sink interface. While it
is tempting to use either the method <code>getOutputDirectory()</code> or the
field <code>outputDirectory</code> directly in order to setup a path for the
output files, this leads most likely to a bug. More precisely, those plugins
will not properly output files when run by the Maven Site Plugin as part of the
site lifecycle. This is best noticed when the output directory for the site is
configured directly in the Maven Site Plugin such that it deviates from the
expression <code>${project.reporting.outputDirectory}</code> that the plugins
use by default. Multi-language site generation is another scenario to exploit
this bug which is illustrated below:</p>
<div class="source"><pre class="prettyprint linenums"><code>public
MyReportMojo extends AbstractMavenReport
{
Modified:
maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html
==============================================================================
--- maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html
(original)
+++ maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html
Thu Feb 9 23:13:59 2023
@@ -272,7 +272,7 @@ under the License.
</build>
</project>
</code></pre></div>
-<p>If <code>merge-descriptors</code> is used, move the handwritten xml file to
<code>$\{basedir\}/src/main/resources/META-INF/plexus</code>.</p></section><section>
+<p>If <code>merge-descriptors</code> is used, move the handwritten xml file to
<code>${basedir}/src/main/resources/META-INF/plexus</code>.</p></section><section>
<h4>Replacing Plexus Javadoc Tags with Plexus Java 5 Annotations</h4>
<p>In your <code>pom.xml</code>, add <code>plexus-component-annotations</code>
dependency:</p>