Author: svn-site-role
Date: Thu Feb 9 22:53:54 2023
New Revision: 1907551
Log:
Site checkin for project Apache Maven Site
Modified:
maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html
maven/website/content/developers/conventions/code.html
maven/website/content/developers/conventions/git.html
maven/website/content/developers/dependency-policies.html
maven/website/content/developers/release/maven-project-release-procedure.html
maven/website/content/developers/retirement-plan-plugins.html
maven/website/content/faq-unoffical.html
maven/website/content/guides/development/guide-documentation-style.html
maven/website/content/guides/development/guide-maven-development.html
maven/website/content/guides/development/guide-plugin-documentation.html
maven/website/content/guides/development/guide-testing-development-plugins.html
maven/website/content/guides/development/guide-testing-releases.html
maven/website/content/guides/getting-started/index.html
maven/website/content/guides/introduction/introduction-to-dependency-mechanism.html
maven/website/content/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
maven/website/content/guides/introduction/introduction-to-profiles.html
maven/website/content/guides/introduction/introduction-to-the-lifecycle.html
maven/website/content/guides/introduction/introduction-to-the-pom.html
maven/website/content/guides/mini/guide-configuring-maven.html
maven/website/content/guides/mini/guide-configuring-plugins.html
maven/website/content/guides/mini/guide-creating-archetypes.html
maven/website/content/guides/mini/guide-default-execution-ids.html
maven/website/content/guides/mini/guide-http-settings.html
maven/website/content/guides/mini/guide-large-scale-centralized-deployments.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-modules.html
maven/website/content/guides/mini/guide-releasing.html
maven/website/content/guides/mini/guide-site.html
maven/website/content/guides/mini/guide-using-extensions.html
maven/website/content/guides/mini/guide-using-toolchains.html
maven/website/content/guides/mini/guide-wagon-providers.html
maven/website/content/guides/plugin/guide-java-plugin-development.html
maven/website/content/guides/plugin/guide-java-report-plugin-development.html
maven/website/content/maven-site-1.0-site.jar
maven/website/content/plugin-developers/common-bugs.html
maven/website/content/plugins/index.html
maven/website/content/repository/central-index.html
maven/website/content/settings.html
Modified:
maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html
==============================================================================
--- maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html
(original)
+++ maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html
Thu Feb 9 22:53:54 2023
@@ -174,7 +174,7 @@ same could be done for Groovy, or Interc
The problem with this is that it's a hack. If xpp3dom/plexus utils is updated
and the plugin requires the new xpp3dom class, which has a new method for
instance, this will break the plugin.</p>
<p>About this specific issue (MNG-3012): The best solution is to only share
java., javax., and core maven api classes, so we can no longer export anything
outside the plugin api (which includes maven-model, maven-project,
maven-settings e.a.). This would require to phase out plugin.getConfiguration()
and other model methods that return xpp3dom classes, and let them return
interfaces present in the maven core api. Those interfaces would have an
implementation class that implements both that interface and extends xpp3dom,
which will be hidden for the plugin. Another solution could be to use
xmlplexusconfiguration</p>
<p>There's one more solution to consider; using ASM to rewrite plugins as
they're loaded. We could add code modifiers that workaround incompatibilities
by detecting usage patterns, like (Xpp3Dom) plugin.getConfiguration(). An
example could be to modify the code to wrap Xpp3DomParser.parse( new
StringReader( String.valueOf( /plugin.getConfiguration()/ ) ) ) around the
call. This is even more of a hack though. Perhaps a mojo that scans for plugin
incompatibilities using ASM is more feasible (no code modification).</p>
-<p>So the basic problem we're up against is that there can be core api changes
between major versions that pose incompatibilities for plugins written against
an older version. The simplest solution would be to let plugins specify the
maven versions they work against (which is partly present: 2.0.6. If this field
supports a versionrange, or we'd default the version interpretation above to
mean [2.0.6,2.1), we can detect plugins that won't run. The shading mentioned
above is solving only one incompatibility problem, and there are bound to be
more. Maybe we even need 2 versions of a plugin at some point, targeted toward
different maven versions, though I'd really like to avoid that. But we cannot
just assume our 2.0 plugin api will never change across ‘major’
(read: minor) releases.</p>
+<p>So the basic problem we're up against is that there can be core api changes
between major versions that pose incompatibilities for plugins written against
an older version. The simplest solution would be to let plugins specify the
maven versions they work against (which is partly present:
<code><requires><mavenVersion>2.0.6</mavenVersion></requires></code>.
If this field supports a versionrange, or we'd default the version
interpretation above to mean [2.0.6,2.1), we can detect plugins that won't run.
The shading mentioned above is solving only one incompatibility problem, and
there are bound to be more. Maybe we even need 2 versions of a plugin at some
point, targeted toward different maven versions, though I'd really like to
avoid that. But we cannot just assume our 2.0 plugin api will never change
across ‘major’ (read: minor) releases.</p>
<p>h3. Strategies for ensuring backward compatibility</p>
<ul>
Modified: maven/website/content/developers/conventions/code.html
==============================================================================
--- maven/website/content/developers/conventions/code.html (original)
+++ maven/website/content/developers/conventions/code.html Thu Feb 9 22:53:54
2023
@@ -235,7 +235,7 @@ under the License.
<p>import <strong>all other imports</strong></p></li>
</ul>
<p>all imports in each group should be sorted alphabetically.</p>
-<p>To ensure a package import order consistent with the layout described
above, download
<code>[maven-eclipse-importorder.txt](https://gitbox.apache.org/repos/asf?p\=maven-shared-resources.git;a\=blob_plain;f\=src/main/resources/config/maven-eclipse-importorder.txt;hb\=HEAD)</code>,
select <em>Window > Preferences</em> and navigate to <em>Java > Code
Style > Organize Imports</em>. Click on <em>Import…</em> and select
the downloaded file to change the import order.</p></section><section>
+<p>To ensure a package import order consistent with the layout described
above, download
<code>[maven-eclipse-importorder.txt](https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=blob_plain;f=src/main/resources/config/maven-eclipse-importorder.txt;hb=HEAD)</code>,
select <em>Window > Preferences</em> and navigate to <em>Java > Code
Style > Organize Imports</em>. Click on <em>Import…</em> and select
the downloaded file to change the import order.</p></section><section>
<h4>JavaDoc Convention</h4>
<p>TO BE DISCUSSED</p></section></section><section>
<h3>XML</h3><section>
@@ -320,23 +320,23 @@ under the License.
</project>
</code></pre></div>
<p><strong>Comments</strong>:</p>
-<p>1 The <project/> element is always on one line.</p>
-<p>1 The blocks are voluntary separated by a new line to improve the
readingness.</p>
-<p>1 The dependencies in <dependencies/> and
<dependencyManagement/> tags have no specific ordering. Developers are
free to choose the ordering, but grouping dependencies by topics (like groupId
i.e. <code>org.apache.maven</code>) is a good practice.</p></section><section>
+<p>1 The <code><project></code> element is always on one line.</p>
+<p>1 The blocks are voluntary separated by a new line to improve the
readiness.</p>
+<p>1 The dependencies in <code><dependencies></code> and
<code><dependencyManagement></code> tags have no specific ordering.
Developers are free to choose the ordering, but grouping dependencies by topics
(like groupId i.e. <code>org.apache.maven</code>) is a good
practice.</p></section><section>
<h4>XDOC Code Convention</h4>
<p>For consistency and readability reasons, XDOC files should respect:</p>
<ul>
<li>
-<p><strong>Metadata</strong>: Always specify metadata in the
<properties/> tag.</p></li>
+<p><strong>Metadata</strong>: Always specify metadata in the
<code><properties></code> tag.</p></li>
<li>
-<p><strong>Sections</strong>: Always use a new line with indentation for
<section/> tags.</p></li>
+<p><strong>Sections</strong>: Always use a new line with indentation for
<code><section></code> tags.</p></li>
</ul></section><section>
<h4>FML Code Convention</h4>
<p>For readability reasons, FML files should respect:</p>
<ul>
-<li><strong>FAQ</strong>: Always use a new line with indentation for
<faq/> tags.</li>
+<li><strong>FAQ</strong>: Always use a new line with indentation for
<code><faq></code> tags.</li>
</ul><!-- * {APT} Do we need any specific APT style/convention? -->
</section></section></section></section>
</main>
Modified: maven/website/content/developers/conventions/git.html
==============================================================================
--- maven/website/content/developers/conventions/git.html (original)
+++ maven/website/content/developers/conventions/git.html Thu Feb 9 22:53:54
2023
@@ -156,7 +156,7 @@ under the License.
<p>This document describes how developers should use Git.</p><section>
<h3>Git Configuration</h3><section>
<h4>For contributors who are not committers</h4>
-<p>Apache git repositories are at _ <<>>. However, the ASF uses
clones on github.com to make it easier for people to contribute changes via
pull requests.<a href="git://git.apache.org_"
class="externalLink">git://git.apache.org_</a></p>
+<p>Apache git repositories are at <em><a href="git://git.apache.org"
class="externalLink">git://git.apache.org</a></em>. However, the ASF uses
clones on github.com to make it easier for people to contribute changes via
pull requests.</p>
<p>To contribute to a Maven component that is maintained in git, please follow
these steps:</p>
<p>1 create a JIRA for bug or improvement that you wish to work on. The Maven
project uses JIRA to organize and track our work, and in particular to keep
track of which changes are included in which releases.</p>
<p>1 Make a fork of the official ASF clone from github.com. For example,
<code>https://github.com/apache/maven-scm</code>.</p>
Modified: maven/website/content/developers/dependency-policies.html
==============================================================================
--- maven/website/content/developers/dependency-policies.html (original)
+++ maven/website/content/developers/dependency-policies.html Thu Feb 9
22:53:54 2023
@@ -162,7 +162,7 @@ under the License.
<h2>Maven Dependency Policies</h2><section>
<h3>Scope</h3>
<p>This page describes the policies around the use of dependencies by the
Apache Maven Developers in the process of developing Apache Maven itself.</p>
-<p>This page does not apply to projects hosted outside of the Apache Maven
project. In order to remove all doubt, this page only applies to code which has
a Github URL that starts with <code>https://github.com/apache/maven</code> or a
Gitbox URL starting with
<code>https://gitbox.apache.org/repos/asf?p\=maven</code></p>
+<p>This page does not apply to projects hosted outside of the Apache Maven
project. In order to remove all doubt, this page only applies to code which has
a Github URL that starts with <code>https://github.com/apache/maven</code> or a
Gitbox URL starting with
<code>https://gitbox.apache.org/repos/asf?p=maven</code></p>
<p>If you have stumbled across this page and you are working on code that does
not have a Github URL starting with
<code>https://github.com/apache/maven</code> then this page does not apply to
you.</p></section><section>
<h3>Background</h3>
<p>The Apache Maven PMC is tasked with ensuring (among other things) that all
legal issues are addressed and that each and every release is the product of
the community as a whole.</p>
Modified:
maven/website/content/developers/release/maven-project-release-procedure.html
==============================================================================
---
maven/website/content/developers/release/maven-project-release-procedure.html
(original)
+++
maven/website/content/developers/release/maven-project-release-procedure.html
Thu Feb 9 22:53:54 2023
@@ -169,7 +169,7 @@ under the License.
<li>
<p>you have JDK 8 installed and on your shell's path to build Maven 3.7.0+.
Details about minimum JDK version to build an appropriate version can be found
here: <a
href="/docs/history.html">https://maven.apache.org/docs/history.html</a></p></li>
<li>
-<p>if you receive an OutOfMemoryError during the build, make sure to have set
the environment variable <code>MAVEN_OPTS\=-Xmx512m</code></p></li>
+<p>if you receive an OutOfMemoryError during the build, make sure to have set
the environment variable <code>MAVEN_OPTS=-Xmx512m</code></p></li>
<li>
<p>you must use Maven 3.3.9+.</p></li>
<li>
@@ -278,17 +278,17 @@ The vote has been canceled.
<li>
<p>drop your staging repository as described in <a
href="https://www.apache.org/dev/publishing-maven-artifacts.html";
class="externalLink">Drop a repository</a></p></li>
<li>
-<p>create new version for next round <code>Y.Z\+1</code></p></li>
+<p>create new version for next round <code>Y.Z+1</code></p></li>
<li>
-<p>assign issues from version <code>Y.Z</code> also to version
<code>Y.Z\+1</code></p></li>
+<p>assign issues from version <code>Y.Z</code> also to version
<code>Y.Z+1</code></p></li>
<li>
<p>mark the <code>Y.Z</code> version as <strong>archived</strong></p></li>
<li>
-<p>report found issues and assign them to version <code>Y.Z\+1</code></p></li>
+<p>report found issues and assign them to version <code>Y.Z+1</code></p></li>
<li>
<p>fix found issues</p></li>
</ul>
-<p>Start the process for version <code>Y.Z\+1</code> from the
beginning.</p></section></section><section>
+<p>Start the process for version <code>Y.Z+1</code> from the
beginning.</p></section></section><section>
<h3>Copy the source release to the Apache Distribution Area</h3>
<p>The official Apache release is the ‘source-release’ bundle
distributed in <code>www.apache.org/dist</code>, as described in <a
href="https://www.apache.org/dev/release-distribution";
class="externalLink">Apache Release Distribution Policy</a>. All releases for
Maven must be copied to <a href="https://www.apache.org/dist/maven/";
class="externalLink">the official Maven release area</a>.</p>
<p>The release area is maintained with svnpubsub. To deliver a release, you
add it to <a href="https://dist.apache.org/repos/dist/release/maven";
class="externalLink">the subversion repository for the dist area</a>: add the
release, its signature and sha512 checksum files, copying them from
<code>target/checkout/target/</code> directory created during <code>mvn
release:perform</code> step. Currently this requires to be in maven-pmc group
(see <a href="https://issues.apache.org/jira/browse/INFRA-5945";
class="externalLink">INFRA-5945</a>). If you are not a PMC member, drop a line
to <em><a href="mailto:[email protected]";
class="externalLink">[email protected]</a></em> and ask them to do this
step (and the next one) for you: the PMC member will get the source release
bundle and its signature from Nexus staging repository and will create sha512
checksum file by hand, for example using shell:</p>
@@ -313,7 +313,7 @@ wagon/wagon-2.2-source-release.zip.sha51
<p>As above, deploy the web site if appropriate and update the project site
for the new release: use <a
href="../website/component-reference-documentation-helper.html">Component
Reference Documentation Helper</a> to generate commands or see <a
href="../website/deploy-component-reference-documentation.html#Publishing_versioned_component_reference_documentation">Publishing
versioned component reference documentation</a> for explanations. Note that
not all projects follow these conventions exactly.</p>
<p>In case there's an overview table with version (e.g. <a
href="/plugins/index.html">plugins</a> and <a
href="/shared/index.html">shared</a>) you can directly edit it on the github
page.</p>
<p>1 Update the version tracking in JIRA</p>
-<p>In the relevant project, go to Administration, then Versions. Mark the
<code>Y.Z</code> version as ‘released’. Create version
<code>Y.Z\+1</code>, if that hasn't already been done. You may also archive any
deprecated releases (milestones or alphas) at this time.</p>
+<p>In the relevant project, go to Administration, then Versions. Mark the
<code>Y.Z</code> version as ‘released’. Create version
<code>Y.Z+1</code>, if that hasn't already been done. You may also archive any
deprecated releases (milestones or alphas) at this time.</p>
<p>Note: Currently this requires to be in the maven-pmc group. So, if you
don't see the Administration option in JIRA, kindly ask <em><a
href="mailto:[email protected]";
class="externalLink">[email protected]</a></em> to do this step for
you.</p>
<p>1 Wait for everything to sync</p>
<p>a Sync to <a href="https://repo.maven.apache.org/maven2/org/apache/maven/";
class="externalLink">Maven Central</a></p>
Modified: maven/website/content/developers/retirement-plan-plugins.html
==============================================================================
--- maven/website/content/developers/retirement-plan-plugins.html (original)
+++ maven/website/content/developers/retirement-plan-plugins.html Thu Feb 9
22:53:54 2023
@@ -220,7 +220,7 @@ I will continue with the steps required
<div class="source"><pre class="prettyprint linenums"><code>Note: This plugin
has retired from the Apache Maven project,
but has moved to the <Organization> <Project> project.
</code></pre></div>
-<p>1 Add " (RETIRED)" at the end of
<code>\<project\></code>/<code>\<name\></code> in the plugin's
<code>pom.xml</code>. This will show up on every page of the generated site.</p>
+<p>1 Add " (RETIRED)" at the end of <code><project>
<name></code> in the plugin's <code>pom.xml</code>. This will show up on
every page of the generated site.</p>
<p>1 Go ahead with <a
href="./release/maven-project-release-procedure.html">the standard release
process</a>, making sure that you follow the exceptions mentioned above
regarding the site deployment.</p>
<p>1 When updating the plugins page, move Maven Foo Plugin to under the
“Retired” heading. Remove the SVN and JIRA links and add the date
of retirement.</p>
<p>1 When updating the version in JIRA, do not add Y.Z+1 and make sure you
remove any future versions.</p></section><section>
Modified: maven/website/content/faq-unoffical.html
==============================================================================
--- maven/website/content/faq-unoffical.html (original)
+++ maven/website/content/faq-unoffical.html Thu Feb 9 22:53:54 2023
@@ -1619,7 +1619,7 @@ and A declares the following:
<h3>What is the purpose of remote repository (other than ibilbilo)?</h3>
<p>To store stuff that is not in ibiblio. An example of this is your own
stuff.</p></section><section>
<h3>Whenever a file is modified in a maven project how is the SNAPSHOT jar
updated in the remote repository?</h3>
-<p>Using mvn deploy, after inserting proper section into your
POM</p></section><section>
+<p>Using mvn deploy, after inserting proper
<code><distributionManagement></code> section into your
POM</p></section><section>
<h3>Is maven ‘deploy’ goal and actually copying of a dependency
or artifact jar to remote repository same?</h3>
<p>Actually, simply copying the artifact to the repository is not the same as
using deploy. The deploy goal will update various metadata files, create the
md5 and sha1 checksum files, and can optionally create missing POM files etc
along with actually copying the artifact file.
So there is a significant difference between the copying the file and using
deploy.</p></section><section>
Modified:
maven/website/content/guides/development/guide-documentation-style.html
==============================================================================
--- maven/website/content/guides/development/guide-documentation-style.html
(original)
+++ maven/website/content/guides/development/guide-documentation-style.html Thu
Feb 9 22:53:54 2023
@@ -190,7 +190,7 @@ under the License.
...
</project>
</code></pre></div>
-<p>As you can see above the <code>\<distributionManagement\></code>
element is indented once (=2 spaces), the <code>\<site\></code> element
is indented twice (=4 spaces), and the <code>\<id\></code> is indented
three times (=6 spaces).</p></section></section><section>
+<p>As you can see above the <code><distributionManagement></code>
element is indented once (=2 spaces), the <code><site></code> element is
indented twice (=4 spaces), and the <code><id></code> is indented three
times (=6 spaces).</p></section></section><section>
<h3>Naming Documentation Files</h3>
<p>All file names should replace space by a hyphen (-), for instance for this
given APT document:</p>
Modified: maven/website/content/guides/development/guide-maven-development.html
==============================================================================
--- maven/website/content/guides/development/guide-maven-development.html
(original)
+++ maven/website/content/guides/development/guide-maven-development.html Thu
Feb 9 22:53:54 2023
@@ -182,7 +182,7 @@ under the License.
<li>
<p>If this was a new piece of work without a JIRA issue, create a JIRA issue
for it now.</p></li>
<li>
-<p>Name the branch after the issue number; the branch name would start with
<code>\<jira-project-id\>-\<ticket-id\></code>.</p></li>
+<p>Name the branch after the issue number; the branch name would start with
<code><jira-project-id>-<ticket-id></code>.</p></li>
<li>
<p>Push your branch with the commit(s) to your fork.</p></li>
<li>
Modified:
maven/website/content/guides/development/guide-plugin-documentation.html
==============================================================================
--- maven/website/content/guides/development/guide-plugin-documentation.html
(original)
+++ maven/website/content/guides/development/guide-plugin-documentation.html
Thu Feb 9 22:53:54 2023
@@ -161,30 +161,30 @@ under the License.
<ul>
<li>
-<p><code>\<modelVersion\></code> - POM model version, currently
4.0.0</p></li>
+<p><code><modelVersion></code> - POM model version, currently
4.0.0</p></li>
<li>
-<p><code>\<groupId\></code> - the package name</p></li>
+<p><code><groupId></code> - the package name</p></li>
<li>
-<p><code>\<artifactId\></code> - artifact name</p></li>
+<p><code><artifactId></code> - artifact name</p></li>
<li>
-<p><code>\<packaging\></code> - type of artifact produced by the
POM</p></li>
+<p><code><packaging></code> - type of artifact produced by the
POM</p></li>
<li>
-<p><code>\<version\></code> - the plugin version</p></li>
+<p><code><version></code> - the plugin version</p></li>
</ul></section><section>
<h4>Optional Elements</h4>
<p>These might be optional elements in a valid POM but they are important
basic project information required by the users to effectively use the
plugin:</p>
<ul>
<li>
-<p><code>\<name\></code> - plugin's name, <em>Maven NNN Plugin</em> for
plugins hosted at the Maven project or <em>NNN Maven Plugin</em> for all
others</p></li>
+<p><code><name></code> - plugin's name, <em>Maven NNN Plugin</em> for
plugins hosted at the Maven project or <em>NNN Maven Plugin</em> for all
others</p></li>
<li>
-<p><code>\<description\></code> - project description, an overview of
what the plugin can do</p></li>
+<p><code><description></code> - project description, an overview of what
the plugin can do</p></li>
<li>
-<p><code>\<url\></code> - the site of the plugin, normally
<em>maven.apache.org</em> or <em>org.mojohaus</em></p></li>
+<p><code><url></code> - the site of the plugin, normally
<em>maven.apache.org</em> or <em>org.mojohaus</em></p></li>
<li>
-<p><code>\<prerequisites\></code> - the minimum version of Maven
required to use this plugin</p></li>
+<p><code><prerequisites></code> - the minimum version of Maven required
to use this plugin</p></li>
<li>
-<p><code>\<issueManagement\></code> - describes the system used for
reporting problems and modification requests</p></li>
+<p><code><issueManagement></code> - describes the system used for
reporting problems and modification requests</p></li>
</ul>
<div class="source"><pre class="prettyprint linenums"><code><project>
@@ -199,9 +199,9 @@ under the License.
<ul>
<li>
-<p><code>\<inceptionYear\></code> - year the plugin was first
created</p></li>
+<p><code><inceptionYear></code> - year the plugin was first
created</p></li>
<li>
-<p><code>\<mailingLists\></code> - lists where other users or the
developers can be contacted for help and discussions</p></li>
+<p><code><mailingLists></code> - lists where other users or the
developers can be contacted for help and discussions</p></li>
</ul>
<div class="source"><pre class="prettyprint linenums"><code><project>
@@ -223,7 +223,7 @@ under the License.
</code></pre></div>
<ul>
-<li><code>\<licenses\></code> - plugin license</li>
+<li><code><licenses></code> - plugin license</li>
</ul>
<div class="source"><pre class="prettyprint linenums"><code><project>
@@ -240,7 +240,7 @@ under the License.
</code></pre></div>
<ul>
-<li><code>\<scm\></code> - the source code management configuration - a
plugin without this would raise suspicion, might not be OSS</li>
+<li><code><scm></code> - the source code management configuration - a
plugin without this would raise suspicion, might not be OSS</li>
</ul>
<div class="source"><pre class="prettyprint linenums"><code><project>
@@ -255,7 +255,7 @@ under the License.
</code></pre></div>
<ul>
-<li><code>\<organization\></code> - the organization maintaining the
plugin, just in case we need someone to blame</li>
+<li><code><organization></code> - the organization maintaining the
plugin, just in case we need someone to blame</li>
</ul>
<div class="source"><pre class="prettyprint linenums"><code><project>
@@ -268,7 +268,7 @@ under the License.
</project>
</code></pre></div></section></section><section>
<h3>Plugin Configuration Parameters</h3>
-<p>The Maven Plugin Plugin is responsible for generating the Plugin Info site
and needs to be added to the <code>\<reporting\></code> section unless it
is already inherited from a parent POM:</p>
+<p>The Maven Plugin Plugin is responsible for generating the Plugin Info site
and needs to be added to the <code><reporting></code> section unless it
is already inherited from a parent POM:</p>
<div class="source"><pre class="prettyprint linenums"><code><project>
[...]
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 22:53:54 2023
@@ -203,7 +203,7 @@ under the License.
</project>
</code></pre></div>
<p><em>Note:</em> These last two techniques mean that <em>every</em> plugin
will be updated to the latest snapshot version.</p>
-<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>
+<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>
Modified: maven/website/content/guides/development/guide-testing-releases.html
==============================================================================
--- maven/website/content/guides/development/guide-testing-releases.html
(original)
+++ maven/website/content/guides/development/guide-testing-releases.html Thu
Feb 9 22:53:54 2023
@@ -166,7 +166,7 @@ under the License.
<li>
<p>add the repository or plugin repository to your POM or settings (see
below)</p></li>
<li>
-<p>ensure you are using the version being released of the artifacts in your
project, e.g. by setting the <code>\<version\></code> in the
<code>\<plugin\></code> tag.</p></li>
+<p>ensure you are using the version being released of the artifacts in your
project, e.g. by setting the <code><version></code> in the
<code><plugin></code> tag.</p></li>
<li>
<p>test the release</p></li>
<li>
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 22:53:54
2023
@@ -281,7 +281,7 @@ under the License.
<li>
<p><strong>groupId</strong> This element indicates the unique identifier of
the organization or group that created the project. The groupId is one of the
key identifiers of a project and is typically based on the fully qualified
domain name of your organization. For example
<code>org.apache.maven.plugins</code> is the designated groupId for all Maven
plugins.</p></li>
<li>
-<p><strong>artifactId</strong> This element indicates the unique base name of
the primary artifact being generated by this project. The primary artifact for
a project is typically a JAR file. Secondary artifacts like source bundles also
use the artifactId as part of their final name. A typical artifact produced by
Maven would have the form <artifactId>-<version>.<extension>
(for example, <code>myapp-1.0.jar</code>).</p></li>
+<p><strong>artifactId</strong> This element indicates the unique base name of
the primary artifact being generated by this project. The primary artifact for
a project is typically a JAR file. Secondary artifacts like source bundles also
use the artifactId as part of their final name. A typical artifact produced by
Maven would have the form
<code><artifactId>-<version>.<extension></code> (for example,
<code>myapp-1.0.jar</code>).</p></li>
<li>
<p><strong>version</strong> This element indicates the version of the artifact
generated by the project. Maven goes a long way to help you with version
management and you will often see the <code>SNAPSHOT</code> designator in a
version, which indicates that a project is in a state of development. We will
discuss the use of <a
href="./index.html#What_is_a_SNAPSHOT_version">snapshots</a> and how they work
further on in this guide.</p></li>
<li>
@@ -609,7 +609,7 @@ InputStream is = getClass().getResourceA
...
</code></pre></div></section><section>
<h3>How do I filter resource files?</h3>
-<p>Sometimes a resource file will need to contain a value that can only be
supplied at build time. To accomplish this in Maven, put a reference to the
property that will contain the value into your resource file using the syntax
<code>$\{\<property name\>\}</code>. The property can be one of the
values defined in your pom.xml, a value defined in the user's settings.xml, a
property defined in an external properties file, or a system property.</p>
+<p>Sometimes a resource file will need to contain a value that can only be
supplied at build time. To accomplish this in Maven, put a reference to the
property that will contain the value into your resource file using the syntax
<code>${<property name>}</code>. The property can be one of the values
defined in your pom.xml, a value defined in the user's settings.xml, a property
defined in an external properties file, or a system property.</p>
<p>To have Maven filter resources when copying, simply set
<code>filtering</code> to true for the resource directory in your
<code>pom.xml</code>:</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"
@@ -975,7 +975,7 @@ command.line.prop=${command.line.prop}
</build>
</project>
</code></pre></div>
-<p>Note the <code>\<packaging\></code> element - this tells Maven to
build as a WAR. Change into the webapp project's directory and try:</p>
+<p>Note the <code><packaging></code> element - this tells Maven to build
as a WAR. Change into the webapp project's directory and try:</p>
<div class="source"><pre class="prettyprint linenums"><code>mvn package
</code></pre></div>
@@ -1025,7 +1025,7 @@ command.line.prop=${command.line.prop}
...
</dependencies>
</code></pre></div>
-<p>Finally, add the following <code>\<parent\></code> element to both of
the other <code>pom.xml</code> files in the subdirectories:</p>
+<p>Finally, add the following <code><parent></code> element to both of
the other <code>pom.xml</code> files in the subdirectories:</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">
@@ -1058,7 +1058,7 @@ command.line.prop=${command.line.prop}
</code></pre></div>
<p>How does this work? Firstly, the parent POM created (called
<code>app</code>), has a packaging of <code>pom</code> and a list of modules
defined. This tells Maven to run all operations over the set of projects
instead of just the current one (to override this behaviour, you can use the
<code>--non-recursive</code> command line option).</p>
<p>Next, we tell the WAR that it requires the <code>my-app</code> JAR. This
does a few things: it makes it available on the classpath to any code in the
WAR (none in this case), it makes sure the JAR is always built before the WAR,
and it indicates to the WAR plugin to include the JAR in its library
directory.</p>
-<p>You may have noticed that <code>junit-4.11.jar</code> was a dependency, but
didn't end up in the WAR. The reason for this is the
<code>\<scope\>test\</scope\></code> element - it is only required
for testing, and so is not included in the web application as the compile time
dependency <code>my-app</code> is.</p>
+<p>You may have noticed that <code>junit-4.11.jar</code> was a dependency, but
didn't end up in the WAR. The reason for this is the
<code><scope>test</scope></code> element - it is only required for
testing, and so is not included in the web application as the compile time
dependency <code>my-app</code> is.</p>
<p>The final step was to include a parent definition. This ensures that the
POM can always be located even if the project is distributed separately from
its parent by looking it up in the repository.</p></section></section></section>
</main>
</div>
Modified:
maven/website/content/guides/introduction/introduction-to-dependency-mechanism.html
==============================================================================
---
maven/website/content/guides/introduction/introduction-to-dependency-mechanism.html
(original)
+++
maven/website/content/guides/introduction/introduction-to-dependency-mechanism.html
Thu Feb 9 22:53:54 2023
@@ -257,7 +257,7 @@ This scope indicates that the dependency
This scope is similar to <code>provided</code> except that you have to provide
the JAR which contains it explicitly. The artifact is always available and is
not looked up in a repository.</p></li>
<li>
<p><strong>import</strong><br />
-This scope is only supported on a dependency of type <code>pom</code> in the
<code>\<dependencyManagement\></code> section. It indicates the
dependency is to be replaced with the effective list of dependencies in the
specified POM's <code>\<dependencyManagement\></code> section. Since they
are replaced, dependencies with a scope of <code>import</code> do not actually
participate in limiting the transitivity of a dependency.</p></li>
+This scope is only supported on a dependency of type <code>pom</code> in the
<code><dependencyManagement></code> section. It indicates the dependency
is to be replaced with the effective list of dependencies in the specified
POM's <code><dependencyManagement></code> section. Since they are
replaced, dependencies with a scope of <code>import</code> do not actually
participate in limiting the transitivity of a dependency.</p></li>
</ul>
<p>Each of the scopes (except for <code>import</code>) affects transitive
dependencies in different ways, as is demonstrated in the table below. If a
dependency is set to the scope in the left column, a transitive dependency of
that dependency with the scope across the top row results in a dependency in
the main project with the scope listed at the intersection. If no scope is
listed, it means the dependency is omitted.</p>
<table class="table table-striped">
@@ -433,7 +433,7 @@ This scope is only supported on a depend
</project>
</code></pre></div>
-<p><strong>NOTE:</strong> In two of these dependency references, we had to
specify the <type/> element. This is because the minimal set of
information for matching a dependency reference against a dependencyManagement
section is actually <strong>{groupId, artifactId, type, classifier}</strong>.
In many cases, these dependencies will refer to jar artifacts with no
classifier. This allows us to shorthand the identity set to <strong>{groupId,
artifactId}</strong>, since the default for the type field is <code>jar</code>,
and the default classifier is null.</p>
+<p><strong>NOTE:</strong> In two of these dependency references, we had to
specify the <code><type></code> element. This is because the minimal set
of information for matching a dependency reference against a
dependencyManagement section is actually <strong>{groupId, artifactId, type,
classifier}</strong>. In many cases, these dependencies will refer to jar
artifacts with no classifier. This allows us to shorthand the identity set to
<strong>{groupId, artifactId}</strong>, since the default for the type field is
<code>jar</code>, and the default classifier is null.</p>
<p>A second, and very important use of the dependency management section is to
control the versions of artifacts used in transitive dependencies. As an
example consider these projects:</p>
<p>Project A:</p>
Modified:
maven/website/content/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
==============================================================================
---
maven/website/content/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
(original)
+++
maven/website/content/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
Thu Feb 9 22:53:54 2023
@@ -175,7 +175,7 @@ under the License.
<h4>Why use optional dependencies?</h4>
<p>Optional dependencies save space and memory. They prevent problematic jars
that violate a license agreement or cause classpath issues from being bundled
into a WAR, EAR, fat jar, or the like.</p></section><section>
<h4>How do I use the optional tag?</h4>
-<p>A dependency is declared optional by setting the
<code>\<optional\></code> element to true in its dependency
declaration:</p>
+<p>A dependency is declared optional by setting the
<code><optional></code> element to true in its dependency declaration:</p>
<div class="source"><pre class="prettyprint linenums"><code>
<project>
@@ -211,7 +211,7 @@ Project-X -> Project-A
<h3>Dependency Exclusions</h3>
<p>Since Maven resolves dependencies transitively, it is possible for unwanted
dependencies to be included in your project's classpath. For example, a certain
older jar may have security issues or be incompatible with the Java version
you're using. To address this, Maven allows you to exclude specific
dependencies. Exclusions are set on a specific dependency in your POM, and are
targeted at a specific groupId and artifactId. When you build your project,
that artifact will not be added to your project's classpath <em>by way of the
dependency in which the exclusion was declared</em>.</p><section>
<h4>How to use dependency exclusions</h4>
-<p>Add an <code>\<exclusions\></code> element in the
<code>\<dependency\></code> element by which the problematic jar is
included.</p>
+<p>Add an <code><exclusions></code> element in the
<code><dependency></code> element by which the problematic jar is
included.</p>
<div class="source"><pre class="prettyprint linenums"><code>
<project>
@@ -248,7 +248,7 @@ Project-A
<div class="source"><pre class="prettyprint linenums"><code>B, C, D, E, F
</code></pre></div>
-<p>Suppose you don't want project D and its dependencies to be added to
Project A's classpath because some of Project-D's dependencies are missing from
the repository, and you don't need the functionality in Project-B that depends
on Project-D anyway. Project-B's developers could have marked the dependency on
Project-D <code>\<optional\>true\</optional\></code>:</p>
+<p>Suppose you don't want project D and its dependencies to be added to
Project A's classpath because some of Project-D's dependencies are missing from
the repository, and you don't need the functionality in Project-B that depends
on Project-D anyway. Project-B's developers could have marked the dependency on
Project-D <code><optional>true</optional></code>:</p>
<div class="source"><pre class="prettyprint linenums"><code><dependency>
<groupId>sample.ProjectD</groupId>
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 22:53:54 2023
@@ -194,7 +194,7 @@ under the License.
<li>
<p><a href="Profiles_in_POMs">Profiles in POMs</a></p></li>
<li>
-<p><a href="POM_elements_outside_.3Cprofiles.3E">POM elements outside
<profiles></a></p></li>
+<p><a href="POM_elements_outside_.3Cprofiles.3E">POM elements outside
<code><profiles></code></a></p></li>
<li>
<p><a href="Profile_Order">Profile Order</a></p></li>
<li>
@@ -258,11 +258,11 @@ under the License.
<h4>Details on profile activation</h4><section>
<h5>Explicit profile activation</h5>
<p>Profiles can be explicitly specified using the <code>-P</code> command line
flag.</p>
-<p>This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
<code>\<activeProfiles\></code> section in <code>settings.xml</code>.
From Maven 4 onward, Maven will refuse to activate or deactivate a profile that
cannot be resolved. To prevent this, prefix the profile identifier with an
<code>?</code>, marking it as optional:</p>
+<p>This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
<code><activeProfiles></code> section in <code>settings.xml</code>. From
Maven 4 onward, Maven will refuse to activate or deactivate a profile that
cannot be resolved. To prevent this, prefix the profile identifier with an
<code>?</code>, marking it as optional:</p>
<div class="source"><pre class="prettyprint linenums"><code>mvn
groupId:artifactId:goal -P profile-1,profile-2,?profile-3
</code></pre></div>
-<p>Profiles can be activated in the Maven settings, via the
<code>\<activeProfiles\></code> section. This section takes a list of
<code>\<activeProfile\></code> elements, each containing a profile-id
inside.</p>
+<p>Profiles can be activated in the Maven settings, via the
<code><activeProfiles></code> section. This section takes a list of
<code><activeProfile></code> elements, each containing a profile-id
inside.</p>
<div class="source"><pre class="prettyprint linenums"><code><settings>
...
@@ -272,9 +272,9 @@ under the License.
...
</settings>
</code></pre></div>
-<p>Profiles listed in the <code>\<activeProfiles\></code> tag would be
activated by default every time a project use it.</p></section><section>
+<p>Profiles listed in the <code><activeProfiles></code> tag would be
activated by default every time a project use it.</p></section><section>
<h5>Implicit profile activation</h5>
-<p>Profiles can be automatically triggered based on the detected state of the
build environment. These triggers are specified via an
<code>\<activation\></code> section in the profile itself. Currently,
this detection is limited to JDK version matching, operating system matching or
the presence/the value of a system property. Here are some examples.</p>JDK
+<p>Profiles can be automatically triggered based on the detected state of the
build environment. These triggers are specified via an
<code><activation></code> section in the profile itself. Currently, this
detection is limited to JDK version matching, operating system matching or the
presence/the value of a system property. Here are some examples.</p>JDK
<p>The following configuration will trigger the profile when the JDK's version
<em>starts with</em> “1.4” (eg. “1.4.0_08”,
“1.4.2_07”, “1.4”), in particular it <em>won't be
active</em> for <strong>newer</strong> versions like “1.8” or
“11”:</p>
<div class="source"><pre class="prettyprint linenums"><code><profiles>
@@ -406,7 +406,7 @@ mvn groupId:artifactId:goal -Ddebug=fals
</profile>
</profiles>
</code></pre></div>
-<p>As of Maven 2.0.9, the tags <code>\<exists\></code> and
<code>\<missing\></code> could be interpolated. Supported variables are
system properties like <code>$\{user.home\}</code> and environment variables
like <code>$\{env.HOME\}</code>. Please note that properties and values defined
in the POM itself are not available for interpolation here, e.g. the above
example activator cannot use <code>$\{project.build.directory\}</code> but
needs to hard-code the path <code>target</code>.</p>
+<p>As of Maven 2.0.9, the tags <code><exists></code> and
<code><missing></code> could be interpolated. Supported variables are
system properties like <code>${user.home}</code> and environment variables like
<code>${env.HOME}</code>. Please note that properties and values defined in the
POM itself are not available for interpolation here, e.g. the above example
activator cannot use <code>${project.build.directory}</code> but needs to
hard-code the path <code>target</code>.</p>
<p>Profiles can also be active by default using a configuration like the
following:</p>
<div class="source"><pre class="prettyprint linenums"><code><profiles>
@@ -434,53 +434,53 @@ mvn groupId:artifactId:goal -Ddebug=fals
<p>Now that we've talked about where to specify profiles, and how to activate
them, it will be useful to talk about <em>what</em> you can specify in a
profile. As with the other aspects of profile configuration, this answer is not
straightforward.</p>
<p>Depending on where you choose to configure your profile, you will have
access to varying POM configuration options.</p><section>
<h4>Profiles in external files</h4>
-<p>Profiles specified in external files (i.e in <code>settings.xml</code> or
<code>profiles.xml</code>) are not portable in the strictest sense. Anything
that seems to stand a high chance of changing the result of the build is
restricted to the inline profiles in the POM. Things like repository lists
could simply be a proprietary repository of approved artifacts, and won't
change the outcome of the build. Therefore, you will only be able to modify the
<code>\<repositories\></code> and
<code>\<pluginRepositories\></code> sections, plus an extra
<code>\<properties\></code> section.</p>
-<p>The <code>\<properties\></code> section allows you to specify
free-form key-value pairs which will be included in the interpolation process
for the POM. This allows you to specify a plugin configuration in the form of
<code>$\{profile.provided.path\}</code>.</p></section><section>
+<p>Profiles specified in external files (i.e in <code>settings.xml</code> or
<code>profiles.xml</code>) are not portable in the strictest sense. Anything
that seems to stand a high chance of changing the result of the build is
restricted to the inline profiles in the POM. Things like repository lists
could simply be a proprietary repository of approved artifacts, and won't
change the outcome of the build. Therefore, you will only be able to modify the
<code><repositories></code> and <code><pluginRepositories></code>
sections, plus an extra <code><properties></code> section.</p>
+<p>The <code><properties></code> section allows you to specify free-form
key-value pairs which will be included in the interpolation process for the
POM. This allows you to specify a plugin configuration in the form of
<code>${profile.provided.path}</code>.</p></section><section>
<h4>Profiles in POMs</h4>
<p>On the other hand, if your profiles can be reasonably specified
<em>inside</em> the POM, you have many more options. The trade-off, of course,
is that you can only modify <em>that</em> project and its sub-modules. Since
these profiles are specified inline, and therefore have a better chance of
preserving portability, it's reasonable to say you can add more information to
them without the risk of that information being unavailable to other users.</p>
<p>Profiles specified in the POM can modify <a
href="/ref/current/maven-model/maven.html">the following POM elements</a>:</p>
<ul>
<li>
-<p><code>\<repositories\></code></p></li>
+<p><code><repositories></code></p></li>
<li>
-<p><code>\<pluginRepositories\></code></p></li>
+<p><code><pluginRepositories></code></p></li>
<li>
-<p><code>\<dependencies\></code></p></li>
+<p><code><dependencies></code></p></li>
<li>
-<p><code>\<plugins\></code></p></li>
+<p><code><plugins></code></p></li>
<li>
-<p><code>\<properties\></code> (not actually available in the main POM,
but used behind the scenes)</p></li>
+<p><code><properties></code> (not actually available in the main POM,
but used behind the scenes)</p></li>
<li>
-<p><code>\<modules\></code></p></li>
+<p><code><modules></code></p></li>
<li>
-<p><code>\<reports\></code></p></li>
+<p><code><reports></code></p></li>
<li>
-<p><code>\<reporting\></code></p></li>
+<p><code><reporting></code></p></li>
<li>
-<p><code>\<dependencyManagement\></code></p></li>
+<p><code><dependencyManagement></code></p></li>
<li>
-<p><code>\<distributionManagement\></code></p></li>
+<p><code><distributionManagement></code></p></li>
<li>
-<p>a subset of the <code>\<build\></code> element, which consists
of:</p></li>
+<p>a subset of the <code><build></code> element, which consists
of:</p></li>
<li>
-<p><code>\<defaultGoal\></code></p></li>
+<p><code><defaultGoal></code></p></li>
<li>
-<p><code>\<resources\></code></p></li>
+<p><code><resources></code></p></li>
<li>
-<p><code>\<testResources\></code></p></li>
+<p><code><testResources></code></p></li>
<li>
-<p><code>\<directory\></code></p></li>
+<p><code><directory></code></p></li>
<li>
-<p><code>\<finalName\></code></p></li>
+<p><code><finalName></code></p></li>
<li>
-<p><code>\<filters\></code></p></li>
+<p><code><filters></code></p></li>
<li>
-<p><code>\<pluginManagement\></code></p></li>
+<p><code><pluginManagement></code></p></li>
<li>
-<p><code>\<plugins\></code></p></li>
+<p><code><plugins></code></p></li>
</ul></section><section>
-<h4>POM elements outside <profiles></h4>
+<h4>POM elements outside <code><profiles></code></h4>
<p>We don't allow modification of some POM elements outside of POM-profiles
because these runtime modifications will not be distributed when the POM is
deployed to the repository system, making that person's build of that project
completely unique from others. While you can do this to some extent with the
options given for external profiles, the danger is limited. Another reason is
that this POM info is sometimes being reused from the parent POM.</p>
<p>External files such as <code>settings.xml</code> and
<code>profiles.xml</code> also does not support elements outside the
POM-profiles. Let us take this scenario for elaboration. When the effective POM
get deployed to a remote repository, any person can pickup its info out of the
repository and use it to build a Maven project directly. Now, imagine that if
we can set profiles in dependencies, which is very important to a build, or in
any other elements outside POM-profiles in <code>settings.xml</code> then most
probably we cannot expect someone else to use that POM from the repository and
be able to build it. And we have to also think about how to share the
<code>settings.xml</code> with others. Note that too many files to configure is
very confusing and very hard to maintain. Bottom line is that since this is
build data, it should be in the POM. One of the goals in Maven 2 is to
consolidate all the information needed to run a build into a single file, or
file hierarchy which is
the POM.</p></section></section><section>
<h3>Profile Order</h3>
@@ -571,8 +571,8 @@ mvn groupId:artifactId:goal -Ddebug=fals
</settings>
</code></pre></div>
<p>When you build the <strong>integration-test</strong> lifecycle phase, your
integration tests pass, since the path you've provided allows the test plugin
to install and test this web application.</p>
-<p><em>However</em>, when your colleague attempts to build to
<strong>integration-test</strong>, his build fails spectacularly, complaining
that it cannot resolve the plugin configuration parameter
<code>\<appserverHome\></code>, or worse, that the value of that
parameter - literally <code>$\{appserver.home\}</code> - is invalid (if it
warns you at all).</p>
-<p>Congratulations, your project is now non-portable. Inlining this profile in
your <code>pom.xml</code> can help alleviate this, with the obvious drawback
that each project hierarchy (allowing for the effects of inheritance) now have
to specify this information. Since Maven provides good support for project
inheritance, it's possible to stick this sort of configuration in the
<code>\<pluginManagement\></code> section of a team-level POM or similar,
and simply inherit the paths.</p>
+<p><em>However</em>, when your colleague attempts to build to
<strong>integration-test</strong>, his build fails spectacularly, complaining
that it cannot resolve the plugin configuration parameter
<code><appserverHome></code>, or worse, that the value of that parameter
- literally <code>${appserver.home}</code> - is invalid (if it warns you at
all).</p>
+<p>Congratulations, your project is now non-portable. Inlining this profile in
your <code>pom.xml</code> can help alleviate this, with the obvious drawback
that each project hierarchy (allowing for the effects of inheritance) now have
to specify this information. Since Maven provides good support for project
inheritance, it's possible to stick this sort of configuration in the
<code><pluginManagement></code> section of a team-level POM or similar,
and simply inherit the paths.</p>
<p>Another, less attractive answer might be standardization of development
environments. However, this will tend to compromise the productivity gain that
Maven is capable of providing.</p></section><section>
<h4>Incomplete Specification of a Natural Profile Set</h4>
<p>In addition to the above portability-breaker, it's easy to fail to cover
all cases with your profiles. When you do this, you're usually leaving one of
your target environments high and dry. Let's take the example
<code>pom.xml</code> snippet from above one more time:</p>
@@ -686,7 +686,7 @@ mvn groupId:artifactId:goal -Ddebug=fals
<div class="source"><pre class="prettyprint linenums"><code> mvn
help:effective-pom -P appserverConfig-dev
</code></pre></div>
<p>This will print the effective POM for this build configuration out to the
console. Take note that profiles in the <code>settings.xml</code> takes higher
priority than profiles in the POM. So the profile that has been applied here is
<code>appserverConfig</code> not <code>appserverConfig-dev</code>.</p>
-<p>If you want to redirect the output from the plugin to a file called
<code>effective-pom.xml</code>, use the command-line option
<code>-Doutput\=effective-pom.xml</code>.</p></section><section>
+<p>If you want to redirect the output from the plugin to a file called
<code>effective-pom.xml</code>, use the command-line option
<code>-Doutput=effective-pom.xml</code>.</p></section><section>
<h3>Naming Conventions</h3>
<p>By now you've noticed that profiles are a natural way of addressing the
problem of different build configuration requirements for different target
environments. Above, we discussed the concept of a “natural set”
of profiles to address this situation, and the importance of considering the
whole set of profiles that will be required.</p>
<p>However, the question of how to organize and manage the evolution of that
set is non-trivial as well. Just as a good developer strives to write
self-documenting code, it's important that your profile id's give a hint to
their intended use. One good way to do this is to use the common system
property trigger as part of the name for the profile. This might result in
names like <strong>env-dev</strong>, <strong>env-test</strong>, and
<strong>env-prod</strong> for profiles that are triggered by the system
property <strong>env</strong>. Such a system leaves a highly intuitive hint on
how to activate a build targeted at a particular environment. Thus, to activate
a build for the test environment, you need to activate
<strong>env-test</strong> by issuing:</p>
Modified:
maven/website/content/guides/introduction/introduction-to-the-lifecycle.html
==============================================================================
---
maven/website/content/guides/introduction/introduction-to-the-lifecycle.html
(original)
+++
maven/website/content/guides/introduction/introduction-to-the-lifecycle.html
Thu Feb 9 22:53:54 2023
@@ -242,7 +242,7 @@ under the License.
<h3>Setting Up Your Project to Use the Build Lifecycle</h3>
<p>The build lifecycle is simple enough to use, but when you are constructing
a Maven build for a project, how do you go about assigning tasks to each of
those build phases?</p><section>
<h4>Packaging</h4>
-<p>The first, and most common way, is to set the packaging for your project
via the equally named POM element <code>\<packaging\></code>. Some of the
valid packaging values are <code>jar</code>, <code>war</code>, <code>ear</code>
and <code>pom</code>. If no packaging value has been specified, it will default
to <code>jar</code>.</p>
+<p>The first, and most common way, is to set the packaging for your project
via the equally named POM element <code><packaging></code>. Some of the
valid packaging values are <code>jar</code>, <code>war</code>, <code>ear</code>
and <code>pom</code>. If no packaging value has been specified, it will default
to <code>jar</code>.</p>
<p>Each packaging contains a list of goals to bind to a particular phase. For
example, the <code>jar</code> packaging will bind the following goals to build
phases of the default lifecycle.</p>
<table class="table table-striped">
<thead>
@@ -276,13 +276,13 @@ under the License.
</table>
<p>This is an almost <a
href="/ref/current/maven-core/default-bindings.html">standard set of
bindings</a>; however, some packagings handle them differently. For example, a
project that is purely metadata (packaging value is <code>pom</code>) only
binds goals to the <code>install</code> and <code>deploy</code> phases (for a
complete list of goal-to-build-phase bindings of some of the packaging types,
refer to the <a href="Lifecycle_Reference">Lifecycle Reference</a>).</p>
-<p>Note that for some packaging types to be available, you may also need to
include a particular plugin in the <code>\<build\></code> section of your
POM and specify <code>\<extensions\>true\</extensions\></code> for
that plugin. One example of a plugin that requires this is the Plexus plugin,
which provides a <code>plexus-application</code> and
<code>plexus-service</code> packaging.</p>
+<p>Note that for some packaging types to be available, you may also need to
include a particular plugin in the <code><build></code> section of your
POM and specify <code><extensions>true</extensions></code> for that
plugin. One example of a plugin that requires this is the Plexus plugin, which
provides a <code>plexus-application</code> and <code>plexus-service</code>
packaging.</p>
<p><em><a
href="./introduction-to-the-lifecycle.html">[top]</a>.</em></p></section><section>
<h4>Plugins</h4>
<p>The second way to add goals to phases is to configure plugins in your
project. Plugins are artifacts that provide goals to Maven. Furthermore, a
plugin may have one or more goals wherein each goal represents a capability of
that plugin. For example, the Compiler plugin has two goals:
<code>compile</code> and <code>testCompile</code>. The former compiles the
source code of your main code, while the latter compiles the source code of
your test code.</p>
<p>As you will see in the later sections, plugins can contain information that
indicates which lifecycle phase to bind a goal to. Note that adding the plugin
on its own is not enough information - you must also specify the goals you want
to run as part of your build.</p>
-<p>The goals that are configured will be added to the goals already bound to
the lifecycle from the packaging selected. If more than one goal is bound to a
particular phase, the order used is that those from the packaging are executed
first, followed by those configured in the POM. Note that you can use the
<code>\<executions\></code> element to gain more control over the order
of particular goals.</p>
-<p>For example, the Modello plugin binds by default its goal
<code>modello:java</code> to the <code>generate-sources</code> phase (Note: The
<code>modello:java</code> goal generates Java source codes). So to use the
Modello plugin and have it generate sources from a model and incorporate that
into the build, you would add the following to your POM in the
<code>\<plugins\></code> section of <code>\<build\></code>:</p>
+<p>The goals that are configured will be added to the goals already bound to
the lifecycle from the packaging selected. If more than one goal is bound to a
particular phase, the order used is that those from the packaging are executed
first, followed by those configured in the POM. Note that you can use the
<code><executions></code> element to gain more control over the order of
particular goals.</p>
+<p>For example, the Modello plugin binds by default its goal
<code>modello:java</code> to the <code>generate-sources</code> phase (Note: The
<code>modello:java</code> goal generates Java source codes). So to use the
Modello plugin and have it generate sources from a model and incorporate that
into the build, you would add the following to your POM in the
<code><plugins></code> section of <code><build></code>:</p>
<div class="source"><pre class="prettyprint linenums"><code> <plugin>
<groupId>org.codehaus.modello</groupId>
@@ -303,7 +303,7 @@ under the License.
</executions>
</plugin>
</code></pre></div>
-<p>You might be wondering why that <code>\<executions\></code> element
is there. That is so that you can run the same goal multiple times with
different configuration if needed. Separate executions can also be given an ID
so that during inheritance or the application of profiles you can control
whether goal configuration is merged or turned into an additional execution.</p>
+<p>You might be wondering why that <code><executions></code> element is
there. That is so that you can run the same goal multiple times with different
configuration if needed. Separate executions can also be given an ID so that
during inheritance or the application of profiles you can control whether goal
configuration is merged or turned into an additional execution.</p>
<p>When multiple executions are given that match a particular phase, they are
executed in the order specified in the POM, with inherited executions running
first.</p>
<p>Now, in the case of <code>modello:java</code>, it only makes sense in the
<code>generate-sources</code> phase. But some goals can be used in more than
one phase, and there may not be a sensible default. For those, you can specify
the phase yourself. For example, let's say you have a goal
<code>display:time</code> that echos the current time to the commandline, and
you want it to run in the <code>process-test-resources</code> phase to indicate
when the tests were started. This would be configured like so:</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 22:53:54 2023
@@ -228,7 +228,7 @@ under the License.
<version>1</version>
</project>
</code></pre></div>
-<p>A POM requires that its groupId, artifactId, and version be configured.
These three values form the project's fully qualified artifact name. This is in
the form of <groupId>:<artifactId>:<version>. As for the
example above, its fully qualified artifact name is
“com.mycompany.app:my-app:1”.</p>
+<p>A POM requires that its groupId, artifactId, and version be configured.
These three values form the project's fully qualified artifact name. This is in
the form of <code><groupId>:<artifactId>:<version></code>. As
for the example above, its fully qualified artifact name is
“com.mycompany.app:my-app:1”.</p>
<p>Also, as mentioned in the <a href="What_is_a_POM">first section</a>, if the
configuration details are not specified, Maven will use their defaults. One of
these default values is the packaging type. Every Maven project has a packaging
type. If it is not specified in the POM, then the default value
“jar” would be used.</p>
<p>Furthermore, you can see that in the minimal POM the <em>repositories</em>
were not specified. If you build your project using the minimal POM, it would
inherit the <em>repositories</em> configuration in the Super POM. Therefore
when Maven sees the dependencies in the minimal POM, it would know that these
dependencies will be downloaded from
<code>https://repo.maven.apache.org/maven2</code> which was specified in the
Super POM.</p>
<p><a href="./introduction-to-the-pom.html">[top]</a></p></section><section>
@@ -317,7 +317,7 @@ under the License.
`-- pom.xml
</code></pre></div></section><section>
<h5>The Solution</h5>
-<p>To address this directory structure (or any other directory structure), we
would have to add the <code>\<relativePath\></code> element to our parent
section.</p>
+<p>To address this directory structure (or any other directory structure), we
would have to add the <code><relativePath></code> element to our parent
section.</p>
<div class="source"><pre class="prettyprint linenums"><code><project>
<modelVersion>4.0.0</modelVersion>
@@ -389,7 +389,7 @@ under the License.
</modules>
</project>
</code></pre></div>
-<p>In the revised com.mycompany.app:my-app:1, the packaging section and the
modules sections were added. For the packaging, its value was set to
“pom”, and for the modules section, we have the element
<code>\<module\>my-module\</module\></code>. The value of
<code>\<module\></code> is the relative path from the
com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM (<em>by
practice, we use the module's artifactId as the module directory's
name</em>).</p>
+<p>In the revised com.mycompany.app:my-app:1, the packaging section and the
modules sections were added. For the packaging, its value was set to
“pom”, and for the modules section, we have the element
<code><module>my-module</module></code>. The value of
<code><module></code> is the relative path from the
com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM (<em>by
practice, we use the module's artifactId as the module directory's
name</em>).</p>
<p>Now, whenever a Maven command processes com.mycompany.app:my-app:1, that
same Maven command would be ran against com.mycompany.app:my-module:1 as well.
Furthermore, some commands (goals specifically) handle project aggregation
differently.</p>
<p><a
href="./introduction-to-the-pom.html">[top]</a></p></section></section><section>
<h4>Example 4</h4><section>
Modified: maven/website/content/guides/mini/guide-configuring-maven.html
==============================================================================
--- maven/website/content/guides/mini/guide-configuring-maven.html (original)
+++ maven/website/content/guides/mini/guide-configuring-maven.html Thu Feb 9
22:53:54 2023
@@ -185,7 +185,7 @@ under the License.
<p><em>User</em> - this is configuration specific to a particular user</p></li>
</ul>
<p>The separation is quite clear - the project defines information that
applies to the project, no matter who is building it, while the others both
define settings for the current environment.</p>
-<p><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><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>
@@ -212,7 +212,7 @@ under the License.
<div class="source"><pre class="prettyprint linenums"><code>export
MAVEN_OPTS=-Dmaven.artifact.threads=3
</code></pre></div></section><section>
<h3>Security and Deployment Settings</h3>
-<p>Repositories to deploy to are defined in a project in the
<code>\<distributionManagement\></code> section. However, you cannot put
your username, password, or other security settings in that project. For that
reason, you should add a server definition to your own settings with an
<code>id</code> that matches that of the deployment repository in the
project.</p>
+<p>Repositories to deploy to are defined in a project in the
<code><distributionManagement></code> section. However, you cannot put
your username, password, or other security settings in that project. For that
reason, you should add a server definition to your own settings with an
<code>id</code> that matches that of the deployment repository in the
project.</p>
<p>In addition, some repositories may require authorization to download from,
so the corresponding settings can be specified in a <code>server</code> element
in the same way.</p>
<p>Which settings are required will depend on the type of repository you are
deploying to. As of the first release, only SCP deployments and file
deployments are supported by default, so only the following SCP configuration
is needed:</p>
