Author: svn-site-role
Date: Fri Apr 12 17:19:27 2019
New Revision: 1857421
Log:
Site checkin for project Apache Maven Site
Modified:
maven/website/content/maven-site-1.0-site.jar
maven/website/content/pom.html
Modified: maven/website/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.
Modified: maven/website/content/pom.html
==============================================================================
--- maven/website/content/pom.html (original)
+++ maven/website/content/pom.html Fri Apr 12 17:19:27 2019
@@ -257,7 +257,7 @@ Karl Heinz Marbaise" />
</project></pre></div></div></div>
<div class="section">
<h2><a name="The_Basics">The Basics</a></h2>
-<p>The POM contains all necessary information about a project, as well as
configurations of plugins to be used during the build process. It is,
effectively, the declarative manifestation of the "who",
"what", and "where", while the build lifecycle is the
"when" and "how". That is not to say that the POM cannot
affect the flow of the lifecycle - it can. For example, by configuring the
<tt>maven-antrun-plugin</tt>, one can effectively embed Apache Ant tasks inside
of the POM. It is ultimately a declaration, however. Where as a
<tt>build.xml</tt> tells Ant precisely what to do when it is run (procedural),
a POM states its configuration (declarative). If some external force causes the
lifecycle to skip the Ant plugin execution, it will not stop the plugins that
are executed from doing their magic. This is unlike a <tt>build.xml</tt> file,
where tasks are almost always dependant on the lines executed before it.</p>
+<p>The POM contains all necessary information about a project, as well as
configurations of plugins to be used during the build process. It is,
effectively, the declarative manifestation of the "who",
"what", and "where", while the build lifecycle is the
"when" and "how". That is not to say that the POM cannot
affect the flow of the lifecycle - it can. For example, by configuring the
<tt>maven-antrun-plugin</tt>, one can effectively embed Apache Ant tasks inside
of the POM. It is ultimately a declaration, however. Whereas a
<tt>build.xml</tt> tells Ant precisely what to do when it is run (procedural),
a POM states its configuration (declarative). If some external force causes the
lifecycle to skip the Ant plugin execution, it will not stop the plugins that
are executed from doing their magic. This is unlike a <tt>build.xml</tt> file,
where tasks are almost always dependant on the lines executed before it.</p>
<div class="source"><pre class="prettyprint linenums"><project
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
@@ -1333,7 +1333,7 @@ Display parameters as parsed by Maven (i
<li><b>verified</b>: This project has been verified, and should be considered
finalized.</li></ul></li></ul>
<div class="section">
<h4><a name="Repository">Repository</a></h4>
-<p>Where as the repositories element specifies in the POM the location and
manner in which Maven may download remote artifacts for use by the current
project, distributionManagement specifies where (and how) this project will get
to a remote repository when it is deployed. The repository elements will be
used for snapshot distribution if the snapshotRepository is not defined.</p>
+<p>Whereas the repositories element specifies in the POM the location and
manner in which Maven may download remote artifacts for use by the current
project, distributionManagement specifies where (and how) this project will get
to a remote repository when it is deployed. The repository elements will be
used for snapshot distribution if the snapshotRepository is not defined.</p>
<div class="source"><pre class="prettyprint linenums"><project
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
@@ -1361,7 +1361,7 @@ Display parameters as parsed by Maven (i
<ul>
<li><b>id</b>, <b>name</b>: The <tt>id</tt> is used to uniquely identify this
repository amongst many, and the <tt>name</tt> is a human readable form.</li>
<li><b>uniqueVersion</b>: The unique version takes a <tt>true</tt> or
<tt>false</tt> value to denote whether artifacts deployed to this repository
should get a uniquely generated version number, or use the version number
defined as part of the address.</li>
-<li><b>url</b>: This is the core of the repository element. It specifies both
the location and the transport protocol to be used to transfer a built artifact
(and POM file, and checksum data) to the repository.</li>
+<li><b>url</b>: This is the core of the repository element. It specifies both
the location and the transport protocol used to transfer a built artifact (and
POM file, and checksum data) to the repository.</li>
<li><b>layout</b>: These are the same types and purpose as the layout element
defined in the repository element. They are <tt>default</tt> and
<tt>legacy</tt>.</li></ul></div>
<div class="section">
<h4><a name="Site_Distribution">Site Distribution</a></h4>
@@ -1403,7 +1403,7 @@ Display parameters as parsed by Maven (i
</distributionManagement>
...
</project></pre></div>
-<p>Projects are not static; they are living things (or dying things, as the
case may be). A common thing that happens as projects grow, is that they are
forced to move to more suitable quarters. For example, when your next wildly
successful open source project moves under the Apache umbrella, it would be
good to give your users as heads-up that the project is being renamed to
<tt>org.apache:my-project:1.0</tt>. Besides specifying the new address, it is
also good form to provide a message explaining why.</p></div></div>
+<p>Projects are not static; they are living things (or dying things, as the
case may be). A common thing that happens as projects grow, is that they are
forced to move to more suitable quarters. For example, when your next wildly
successful open source project moves under the Apache umbrella, it would be
good to give users a heads-up that the project is being renamed to
<tt>org.apache:my-project:1.0</tt>. Besides specifying the new address, it is
also good form to provide a message explaining why.</p></div></div>
<div class="section">
<h3><a name="Profiles">Profiles</a></h3>
<p>A new feature of the POM 4.0 is the ability of a project to change settings
depending on the environment where it is being built. A <tt>profile</tt>
element contains both an optional activation (a profile trigger) and the set of
changes to be made to the POM if that profile has been activated. For example,
a project built for a test environment may point to a different database than
that of the final deployment. Or dependencies may be pulled from different
repositories based upon the JDK version used. The elements of profiles are as
follows:</p>
