You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by bu...@apache.org on 2013/04/27 09:29:25 UTC
svn commit: r860084 [21/39] - in /websites/staging/maven/trunk/content: ./
background/ developers/ developers/conventions/ developers/release/
developers/website/ docs/2.0.1/ docs/2.0.10/ docs/2.0.11/ docs/2.0.2/
docs/2.0.3/ docs/2.0.4/ docs/2.0.5/ doc...
Modified: websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-standard-directory-layout.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-standard-directory-layout.html (original)
+++ websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-standard-directory-layout.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -14,7 +14,7 @@
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Jason van Zyl" />
<meta name="Date-Creation-yyyymmdd" content="20100905" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -44,7 +44,7 @@
Introduction to the Standard Directory Layout
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -232,7 +232,59 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Introduction to the Standard Directory Layout<a name="Introduction_to_the_Standard_Directory_Layout"></a></h2><p>Having a common directory layout would allow for users familiar with one Maven project to immediately feel at home in another Maven project. The advantages are analogous to adopting a site-wide look-and-feel.</p><p>The next section documents the directory layout expected by Maven and the directory layout created by Maven. Please try to conform to this structure as much as possible; however, if you can't these settings can be overridden via the project descriptor.</p><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>src/main/java</tt></td><td align="left">Application/Library sources</td></tr><tr class="b"><td align="left"><tt>src/main/resources</tt></td><td align="left">Application/Library resources</td></tr><tr class="a"><td align="left"><tt>src/main/filters</tt></td><td align="left">Resource filter files</td><
/tr><tr class="b"><td align="left"><tt>src/main/assembly</tt></td><td align="left">Assembly descriptors</td></tr><tr class="a"><td align="left"><tt>src/main/config</tt></td><td align="left">Configuration files</td></tr><tr class="b"><td align="left"><tt>src/main/scripts</tt></td><td align="left">Application/Library scripts</td></tr><tr class="a"><td align="left"><tt>src/main/webapp</tt></td><td align="left">Web application sources</td></tr><tr class="b"><td align="left"><tt>src/test/java</tt></td><td align="left">Test sources</td></tr><tr class="a"><td align="left"><tt>src/test/resources</tt></td><td align="left">Test resources</td></tr><tr class="b"><td align="left"><tt>src/test/filters</tt></td><td align="left">Test resource filter files</td></tr><tr class="a"><td align="left"><tt>src/site</tt></td><td align="left">Site</td></tr><tr class="b"><td align="left"><tt>LICENSE.txt</tt></td><td align="left">Project's license</td></tr><tr class="a"><td align="left"><tt>NOTICE.txt<
/tt></td><td align="left">Notices and attributions required by libraries that the project depends on</td></tr><tr class="b"><td align="left"><tt>README.txt</tt></td><td align="left">Project's readme</td></tr></table><p>At the top level files descriptive of the project: a <tt>pom.xml</tt> file (and any properties, <tt>maven.xml</tt> or <tt>build.xml</tt> if using Ant). In addition, there are textual documents meant for the user to be able to read immediately on receiving the source: <tt>README.txt</tt>, <tt>LICENSE.txt</tt>, etc.</p><p>There are just two subdirectories of this structure: <tt>src</tt> and <tt>target</tt>. The only other directories that would be expected here are metadata like <tt>CVS</tt> or <tt>.svn</tt>, and any subprojects in a multiproject build (each of which would be laid out as above).</p><p>The <tt>target</tt> directory is used to house all output of the build.</p><p>The <tt>src</tt> directory contains all of the source material for building the proje
ct, its site and so on. It contains a subdirectory for each type: <tt>main</tt> for the main build artifact, <tt>test</tt> for the unit test code and resources, <tt>site</tt> and so on.</p><p>Within artifact producing source directories (ie. <tt>main</tt> and <tt>test</tt>), there is one directory for the language <tt>java</tt> (under which the normal package hierarchy exists), and one for <tt>resources</tt> (the structure which is copied to the target classpath given the default resource definition).</p><p>If there are other contributing sources to the artifact build, they would be under other subdirectories: for example <tt>src/main/antlr</tt> would contain Antlr grammar definition files.</p></div>
+ <div class="section">
+<h2>Introduction to the Standard Directory Layout<a name="Introduction_to_the_Standard_Directory_Layout"></a></h2>
+<p>Having a common directory layout would allow for users familiar with one Maven project to immediately feel at home in another Maven project. The advantages are analogous to adopting a site-wide look-and-feel.</p>
+<p>The next section documents the directory layout expected by Maven and the directory layout created by Maven. Please try to conform to this structure as much as possible; however, if you can't these settings can be overridden via the project descriptor.</p>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>src/main/java</tt></td>
+<td align="left">Application/Library sources</td></tr>
+<tr class="b">
+<td align="left"><tt>src/main/resources</tt></td>
+<td align="left">Application/Library resources</td></tr>
+<tr class="a">
+<td align="left"><tt>src/main/filters</tt></td>
+<td align="left">Resource filter files</td></tr>
+<tr class="b">
+<td align="left"><tt>src/main/assembly</tt></td>
+<td align="left">Assembly descriptors</td></tr>
+<tr class="a">
+<td align="left"><tt>src/main/config</tt></td>
+<td align="left">Configuration files</td></tr>
+<tr class="b">
+<td align="left"><tt>src/main/scripts</tt></td>
+<td align="left">Application/Library scripts</td></tr>
+<tr class="a">
+<td align="left"><tt>src/main/webapp</tt></td>
+<td align="left">Web application sources</td></tr>
+<tr class="b">
+<td align="left"><tt>src/test/java</tt></td>
+<td align="left">Test sources</td></tr>
+<tr class="a">
+<td align="left"><tt>src/test/resources</tt></td>
+<td align="left">Test resources</td></tr>
+<tr class="b">
+<td align="left"><tt>src/test/filters</tt></td>
+<td align="left">Test resource filter files</td></tr>
+<tr class="a">
+<td align="left"><tt>src/site</tt></td>
+<td align="left">Site</td></tr>
+<tr class="b">
+<td align="left"><tt>LICENSE.txt</tt></td>
+<td align="left">Project's license</td></tr>
+<tr class="a">
+<td align="left"><tt>NOTICE.txt</tt></td>
+<td align="left">Notices and attributions required by libraries that the project depends on</td></tr>
+<tr class="b">
+<td align="left"><tt>README.txt</tt></td>
+<td align="left">Project's readme</td></tr></table>
+<p>At the top level files descriptive of the project: a <tt>pom.xml</tt> file (and any properties, <tt>maven.xml</tt> or <tt>build.xml</tt> if using Ant). In addition, there are textual documents meant for the user to be able to read immediately on receiving the source: <tt>README.txt</tt>, <tt>LICENSE.txt</tt>, etc.</p>
+<p>There are just two subdirectories of this structure: <tt>src</tt> and <tt>target</tt>. The only other directories that would be expected here are metadata like <tt>CVS</tt> or <tt>.svn</tt>, and any subprojects in a multiproject build (each of which would be laid out as above).</p>
+<p>The <tt>target</tt> directory is used to house all output of the build.</p>
+<p>The <tt>src</tt> directory contains all of the source material for building the project, its site and so on. It contains a subdirectory for each type: <tt>main</tt> for the main build artifact, <tt>test</tt> for the unit test code and resources, <tt>site</tt> and so on.</p>
+<p>Within artifact producing source directories (ie. <tt>main</tt> and <tt>test</tt>), there is one directory for the language <tt>java</tt> (under which the normal package hierarchy exists), and one for <tt>resources</tt> (the structure which is copied to the target classpath given the default resource definition).</p>
+<p>If there are other contributing sources to the artifact build, they would be under other subdirectories: for example <tt>src/main/antlr</tt> would contain Antlr grammar definition files.</p></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/mini/guide-3rd-party-jars-local.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-3rd-party-jars-local.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-3rd-party-jars-local.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Jason van Zyl" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Guide to installing 3rd party JARs
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,7 +231,11 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Guide to installing 3rd party JARs<a name="Guide_to_installing_3rd_party_JARs"></a></h2><p>Often times you will have 3rd party JARs that you need to put in your local repository for use in your builds. The JARs must be placed in the local repository in the correct place in order for it to be correctly picked up by Maven. To make this easier, and less error prone, we have provide a goal in the install plug-in which should make this relatively painless. To install a JAR in the local repository use the following command:</p><div class="source"><pre>
+ <div class="section">
+<h2>Guide to installing 3rd party JARs<a name="Guide_to_installing_3rd_party_JARs"></a></h2>
+<p>Often times you will have 3rd party JARs that you need to put in your local repository for use in your builds. The JARs must be placed in the local repository in the correct place in order for it to be correctly picked up by Maven. To make this easier, and less error prone, we have provide a goal in the install plug-in which should make this relatively painless. To install a JAR in the local repository use the following command:</p>
+<div class="source">
+<pre>
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> \
-DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=<packaging>
</pre></div></div>
Modified: websites/staging/maven/trunk/content/guides/mini/guide-3rd-party-jars-remote.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-3rd-party-jars-remote.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-3rd-party-jars-remote.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Allan Ramirez" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Guide to deploying 3rd party JARs to remote repository
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,16 +231,37 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Guide to deploying 3rd party JARs to remote repository<a name="Guide_to_deploying_3rd_party_JARs_to_remote_repository"></a></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 %M2_HOME%/lib.</p><p>Then execute the command:</p><div class="source"><pre>mvn deploy:deploy-file -DgroupId=<group-id> \
+ <div class="section">
+<h2>Guide to deploying 3rd party JARs to remote repository<a name="Guide_to_deploying_3rd_party_JARs_to_remote_repository"></a></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 %M2_HOME%/lib.</p>
+<p>Then execute the command:</p>
+<div class="source">
+<pre>mvn deploy:deploy-file -DgroupId=<group-id> \
-DartifactId=<artifact-id> \
-Dversion=<version> \
-Dpackaging=<type-of-packaging> \
-Dfile=<path-to-file> \
-DrepositoryId=<id-to-map-on-server-section-of-settings.xml> \
- -Durl=<url-of-the-repository-to-deploy></pre></div><div class="section"><h3>Deploying a 3rd party JAR with a generic POM<a name="Deploying_a_3rd_party_JAR_with_a_generic_POM"></a></h3><p>By default, deploy:deploy-file generates a generic POM(.pom) to be deploy together with the 3rd party JAR. To disable this feature we should set the <tt>generatePOM</tt> argument to false.</p><div class="source"><pre>-DgeneratePom=false</pre></div></div><div class="section"><h3>Deploying a 3rd party JAR with a customized POM<a name="Deploying_a_3rd_party_JAR_with_a_customized_POM"></a></h3><p>If a POM is already existing for the 3rd Party JAR and you want to deploy it together with the JAR we should use the <tt>pomFile</tt> argument of the deploy-file goal. See sample below.</p><div class="source"><pre>mvn deploy:deploy-file -DpomFile=<path-to-pom> \
+ -Durl=<url-of-the-repository-to-deploy></pre></div>
+<div class="section">
+<h3>Deploying a 3rd party JAR with a generic POM<a name="Deploying_a_3rd_party_JAR_with_a_generic_POM"></a></h3>
+<p>By default, deploy:deploy-file generates a generic POM(.pom) to be deploy together with the 3rd party JAR. To disable this feature we should set the <tt>generatePOM</tt> argument to false.</p>
+<div class="source">
+<pre>-DgeneratePom=false</pre></div></div>
+<div class="section">
+<h3>Deploying a 3rd party JAR with a customized POM<a name="Deploying_a_3rd_party_JAR_with_a_customized_POM"></a></h3>
+<p>If a POM is already existing for the 3rd Party JAR and you want to deploy it together with the JAR we should use the <tt>pomFile</tt> argument of the deploy-file goal. See sample below.</p>
+<div class="source">
+<pre>mvn deploy:deploy-file -DpomFile=<path-to-pom> \
-Dfile=<path-to-file> \
-DrepositoryId=<id-to-map-on-server-section-of-settings.xml> \
- -Durl=<url-of-the-repository-to-deploy></pre></div><p>Note that <tt>groupId</tt>, <tt>artifactId</tt>, <tt>version</tt> and <tt>packaging</tt> arguments are not included here because deploy-file goal will get these information from the given POM.</p></div><div class="section"><h3>Deploying Source Jars<a name="Deploying_Source_Jars"></a></h3><p>To deploy a 3rd party source jar, packaging should be set to <tt>java-source</tt>, and generatePom should be set to <tt>false</tt>.</p></div></div>
+ -Durl=<url-of-the-repository-to-deploy></pre></div>
+<p>Note that <tt>groupId</tt>, <tt>artifactId</tt>, <tt>version</tt> and <tt>packaging</tt> arguments are not included here because deploy-file goal will get these information from the given POM.</p></div>
+<div class="section">
+<h3>Deploying Source Jars<a name="Deploying_Source_Jars"></a></h3>
+<p>To deploy a 3rd party source jar, packaging should be set to <tt>java-source</tt>, and generatePom should be set to <tt>false</tt>.</p></div></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/mini/guide-archive-configuration.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-archive-configuration.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-archive-configuration.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Brett Porter" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Guide to Configuring Archive Plugins
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,7 +231,15 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Guide to Configuring Archive Plugins<a name="Guide_to_Configuring_Archive_Plugins"></a></h2><p>Many Java archive generating plugins accept the <tt>archive</tt> configuration element to customize the generation of the archive. In the standard Maven Plugins, this includes the <tt>jar</tt>, <tt>war</tt>, <tt>ejb</tt>, <tt>ear</tt> and <tt>assembly</tt> plugins.</p><div class="section"><h3>Disabling Maven Meta Information<a name="Disabling_Maven_Meta_Information"></a></h3><p>By default, Maven generated archives include the <tt>META-INF/maven</tt> directory, which contains the <tt>pom.xml</tt> file used to build the archive, and a <tt>pom.properties</tt> file that includes some basic properties in a small, easier to read format.</p><p>To disable the generation of these files, include the following configuration for your plugin (in this example, the WAR plugin is used):</p><div class="source"><pre><project>
+ <div class="section">
+<h2>Guide to Configuring Archive Plugins<a name="Guide_to_Configuring_Archive_Plugins"></a></h2>
+<p>Many Java archive generating plugins accept the <tt>archive</tt> configuration element to customize the generation of the archive. In the standard Maven Plugins, this includes the <tt>jar</tt>, <tt>war</tt>, <tt>ejb</tt>, <tt>ear</tt> and <tt>assembly</tt> plugins.</p>
+<div class="section">
+<h3>Disabling Maven Meta Information<a name="Disabling_Maven_Meta_Information"></a></h3>
+<p>By default, Maven generated archives include the <tt>META-INF/maven</tt> directory, which contains the <tt>pom.xml</tt> file used to build the archive, and a <tt>pom.properties</tt> file that includes some basic properties in a small, easier to read format.</p>
+<p>To disable the generation of these files, include the following configuration for your plugin (in this example, the WAR plugin is used):</p>
+<div class="source">
+<pre><project>
...
<build>
<plugins>
@@ -249,7 +257,10 @@
</build>
...
</project>
-</pre></div><!-- other things: index, compress --></div><div class="section"><h3>Configuring the Manifest<a name="Configuring_the_Manifest"></a></h3><p>The archive configuration also accepts manifest configuration. See <a href="./guide-manifest.html">Guide to Working with Manifests</a> for more information.</p></div></div>
+</pre></div><!-- other things: index, compress --></div>
+<div class="section">
+<h3>Configuring the Manifest<a name="Configuring_the_Manifest"></a></h3>
+<p>The archive configuration also accepts manifest configuration. See <a href="./guide-manifest.html">Guide to Working with Manifests</a> for more information.</p></div></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/mini/guide-assemblies.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-assemblies.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-assemblies.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Jason van Zyl" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Guide to Creating Assemblies
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,7 +231,11 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Guide to creating assemblies<a name="Guide_to_creating_assemblies"></a></h2><p>The assembly mechanism in Maven 2.x provides an easy way to create distributions using a assembly descriptor and dependency information found in you POM. In order to use the assembly plug-in you need to configure the assembly plug-in in your POM and it might look like the following:</p><div class="source"><pre>
+ <div class="section">
+<h2>Guide to creating assemblies<a name="Guide_to_creating_assemblies"></a></h2>
+<p>The assembly mechanism in Maven 2.x provides an easy way to create distributions using a assembly descriptor and dependency information found in you POM. In order to use the assembly plug-in you need to configure the assembly plug-in in your POM and it might look like the following:</p>
+<div class="source">
+<pre>
<project>
<parent>
<artifactId>maven</artifactId>
@@ -256,7 +260,13 @@
</build>
...
</project>
-</pre></div><p>You'll notice that the assembly descriptor is located in <tt>${basedir}/src/main/assembly</tt> which is the <a href="../introduction/introduction-to-the-standard-directory-layout.html">standard</a> location for assembly descriptors.</p><div class="section"><h3>Creating a binary assembly<a name="Creating_a_binary_assembly"></a></h3><p>This is the most typical usage of the assembly plugin where you are creating a distribution for standard use.</p><div class="source"><pre>
+</pre></div>
+<p>You'll notice that the assembly descriptor is located in <tt>${basedir}/src/main/assembly</tt> which is the <a href="../introduction/introduction-to-the-standard-directory-layout.html">standard</a> location for assembly descriptors.</p>
+<div class="section">
+<h3>Creating a binary assembly<a name="Creating_a_binary_assembly"></a></h3>
+<p>This is the most typical usage of the assembly plugin where you are creating a distribution for standard use.</p>
+<div class="source">
+<pre>
<assembly>
<id>bin</id>
<formats>
@@ -281,7 +291,9 @@
</fileSet>
</fileSets>
</assembly>
-</pre></div><div class="source"><pre>
+</pre></div>
+<div class="source">
+<pre>
<assembly>
<!-- TODO: a jarjar format would be better -->
<id>dep</id>
@@ -312,7 +324,9 @@
</dependencySet>
</dependencySets>
</assembly>
-</pre></div><div class="source"><pre>
+</pre></div>
+<div class="source">
+<pre>
<assembly>
<id>src</id>
<formats>
@@ -334,9 +348,13 @@
</fileSet>
</fileSets>
</assembly>
-</pre></div><div class="source"><pre>
+</pre></div>
+<div class="source">
+<pre>
mvn assembly:assembly
-</pre></div><div class="source"><pre></pre></div></div></div>
+</pre></div>
+<div class="source">
+<pre></pre></div></div></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/mini/guide-attached-tests.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-attached-tests.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-attached-tests.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Jason van Zyl" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Guide to using attached tests
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,7 +231,11 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Guide to using attached tests<a name="Guide_to_using_attached_tests"></a></h2><p>Many times you may want to reuse the tests that you have created for a project in another. For example if you have written <tt>foo-core</tt> and it contains test code in the <tt>${basedir}/src/test/java</tt> it would be useful to package up those compiled tests in a JAR and deploy them for general reuse. To do this you would configure the <tt>maven-jar-plugin</tt> as follows:</p><div class="source"><pre>
+ <div class="section">
+<h2>Guide to using attached tests<a name="Guide_to_using_attached_tests"></a></h2>
+<p>Many times you may want to reuse the tests that you have created for a project in another. For example if you have written <tt>foo-core</tt> and it contains test code in the <tt>${basedir}/src/test/java</tt> it would be useful to package up those compiled tests in a JAR and deploy them for general reuse. To do this you would configure the <tt>maven-jar-plugin</tt> as follows:</p>
+<div class="source">
+<pre>
<project>
<build>
<plugins>
@@ -250,11 +254,26 @@
</plugins>
</build>
</project>
-</pre></div><div class="section"><h3>Installing the attached test JAR<a name="Installing_the_attached_test_JAR"></a></h3><p>In order to install the attached test JAR you simply use the standard <tt>install</tt> phase by executing the following command:</p><div class="source"><pre>
+</pre></div>
+<div class="section">
+<h3>Installing the attached test JAR<a name="Installing_the_attached_test_JAR"></a></h3>
+<p>In order to install the attached test JAR you simply use the standard <tt>install</tt> phase by executing the following command:</p>
+<div class="source">
+<pre>
mvn install
-</pre></div></div><div class="section"><h3>Deploying the attached test JAR<a name="Deploying_the_attached_test_JAR"></a></h3><p>In order to deploy the attached test JAR you simply use the standard <tt>deploy</tt> phase by executing the following command:</p><div class="source"><pre>
+</pre></div></div>
+<div class="section">
+<h3>Deploying the attached test JAR<a name="Deploying_the_attached_test_JAR"></a></h3>
+<p>In order to deploy the attached test JAR you simply use the standard <tt>deploy</tt> phase by executing the following command:</p>
+<div class="source">
+<pre>
mvn deploy
-</pre></div></div><div class="section"><h3>Using the attached test JAR<a name="Using_the_attached_test_JAR"></a></h3><p>In order to use the attached test JAR that was created above you simply specify a dependency on the main artifact with a specified type of <tt>test-jar</tt>:</p><div class="source"><pre>
+</pre></div></div>
+<div class="section">
+<h3>Using the attached test JAR<a name="Using_the_attached_test_JAR"></a></h3>
+<p>In order to use the attached test JAR that was created above you simply specify a dependency on the main artifact with a specified type of <tt>test-jar</tt>:</p>
+<div class="source">
+<pre>
<project>
...
<dependencies>
@@ -268,7 +287,8 @@ mvn deploy
</dependencies>
...
</project>
-</pre></div><p>Note that previous editions of this guide suggested to use <tt><classifier>tests</classifier></tt> instead of <tt><type>test-jar</type></tt>. While this currently works for some cases, it does not properly work during a reactor build of the test JAR module and any consumer if a lifecycle phase prior to <tt>install</tt> is invoked. In such a scenario, Maven will not resolve the test JAR from the output of the reactor build but from the local/remote repository. Apparently, the JAR from the repositories could be outdated or completely missing, causing a build failure (cf. <a class="externalLink" href="http://jira.codehaus.org/browse/MNG-2045">MNG-2045</a>).</p></div></div>
+</pre></div>
+<p>Note that previous editions of this guide suggested to use <tt><classifier>tests</classifier></tt> instead of <tt><type>test-jar</type></tt>. While this currently works for some cases, it does not properly work during a reactor build of the test JAR module and any consumer if a lifecycle phase prior to <tt>install</tt> is invoked. In such a scenario, Maven will not resolve the test JAR from the output of the reactor build but from the local/remote repository. Apparently, the JAR from the repositories could be outdated or completely missing, causing a build failure (cf. <a class="externalLink" href="http://jira.codehaus.org/browse/MNG-2045">MNG-2045</a>).</p></div></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/mini/guide-bash-m2-completion.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-bash-m2-completion.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-bash-m2-completion.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -14,7 +14,7 @@
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Trygve Laugstol
Jason van Zyl" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -44,7 +44,7 @@ Jason van Zyl" />
Guide to Maven 2.x auto completion using BASH
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -232,7 +232,12 @@ Jason van Zyl" />
</div>
<div id="bodyColumn">
<div id="contentBox">
- <!-- Licensed to the Apache Software Foundation (ASF) under one --><!-- or more contributor license agreements. See the NOTICE file --><!-- distributed with this work for additional information --><!-- regarding copyright ownership. The ASF licenses this file --><!-- to you under the Apache License, Version 2.0 (the --><!-- "License"); you may not use this file except in compliance --><!-- with the License. You may obtain a copy of the License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!-- --><!-- Unless required by applicable law or agreed to in writing, --><!-- software distributed under the License is distributed on an --><!-- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY --><!-- KIND, either express or implied. See the License for the --><!-- specific language governing permissions and limitations --><!-- under the License. --><!-- NOTE: For help with the syntax of this file, see: --><!-- http://maven.apache.org/doxia/referen
ces/apt-format.html --><div class="section"><h2>Guide to Maven 2.x auto completion using BASH<a name="Guide_to_Maven_2.x_auto_completion_using_BASH"></a></h2><p>First you must go to the following site to install the BASH programmable auto completion setup if your distro doesn't have it by default. I don't think many do so you'll need to go to the <a class="externalLink" href="http://www.caliban.org/bash/index.shtml#completion">Programmable Completion Website</a>.</p><p>Once you've setup your system for auto completion you need to take the following:</p><div class="source"><pre>
+ <!-- Licensed to the Apache Software Foundation (ASF) under one --><!-- or more contributor license agreements. See the NOTICE file --><!-- distributed with this work for additional information --><!-- regarding copyright ownership. The ASF licenses this file --><!-- to you under the Apache License, Version 2.0 (the --><!-- "License"); you may not use this file except in compliance --><!-- with the License. You may obtain a copy of the License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!-- --><!-- Unless required by applicable law or agreed to in writing, --><!-- software distributed under the License is distributed on an --><!-- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY --><!-- KIND, either express or implied. See the License for the --><!-- specific language governing permissions and limitations --><!-- under the License. --><!-- NOTE: For help with the syntax of this file, see: --><!-- http://maven.apache.org/doxia/referen
ces/apt-format.html --><div class="section">
+<h2>Guide to Maven 2.x auto completion using BASH<a name="Guide_to_Maven_2.x_auto_completion_using_BASH"></a></h2>
+<p>First you must go to the following site to install the BASH programmable auto completion setup if your distro doesn't have it by default. I don't think many do so you'll need to go to the <a class="externalLink" href="http://www.caliban.org/bash/index.shtml#completion">Programmable Completion Website</a>.</p>
+<p>Once you've setup your system for auto completion you need to take the following:</p>
+<div class="source">
+<pre>
#!/bin/bash
_m2_make_goals()
@@ -261,7 +266,8 @@ _m2_complete()
}
complete -F _m2_complete -o filenames mvn
-</pre></div><p>And place it in <tt>/etc/bash_completion.d/m2</tt>. Once you've done that the next time you start up your BASH shell you will have m2 auto completion!</p></div>
+</pre></div>
+<p>And place it in <tt>/etc/bash_completion.d/m2</tt>. Once you've done that the next time you start up your BASH shell you will have m2 auto completion!</p></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/mini/guide-building-for-different-environments.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-building-for-different-environments.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-building-for-different-environments.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="01-Jan-2006" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Building For Different Environments with Maven 2
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,13 +231,30 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Building For Different Environments with Maven 2<a name="Building_For_Different_Environments_with_Maven_2"></a></h2><p>Building the same artifact for different environments has always been an annoyance. You have multiple environments, for instance test and production servers or, maybe a set of servers that run the same application with different configurations. In this guide I'll explain how you can use profiles to build and package artifacts configured for specific environments. See <a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a> for a more in-depth explanation of the profile concept.</p><p>Note:</p><ul><li>This guide assume that you have basic Maven 2 knowledge.</li><li>It will show a way to configure Maven to solve simple configuration set-ups only. By simple configuration set-up I mean cases where you only have a single file or a small set of files that vary for each environment. There are other
and better ways to handle two and many-dimensional configuration issues.<p>This example assume the use of the <a href="../introduction/introduction-to-the-standard-directory-layout.html">Standard Directory Layout</a>.</p><div><pre>pom.xml
+ <div class="section">
+<h2>Building For Different Environments with Maven 2<a name="Building_For_Different_Environments_with_Maven_2"></a></h2>
+<p>Building the same artifact for different environments has always been an annoyance. You have multiple environments, for instance test and production servers or, maybe a set of servers that run the same application with different configurations. In this guide I'll explain how you can use profiles to build and package artifacts configured for specific environments. See <a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a> for a more in-depth explanation of the profile concept.</p>
+<p>Note:</p>
+<ul>
+<li>This guide assume that you have basic Maven 2 knowledge.</li>
+<li>It will show a way to configure Maven to solve simple configuration set-ups only. By simple configuration set-up I mean cases where you only have a single file or a small set of files that vary for each environment. There are other and better ways to handle two and many-dimensional configuration issues.
+<p>This example assume the use of the <a href="../introduction/introduction-to-the-standard-directory-layout.html">Standard Directory Layout</a>.</p>
+<div>
+<pre>pom.xml
src/
main/
java/
resources/
test/
- java/</pre></div></li></ul><p>Under <tt>src/main/resources</tt> there are three files:</p><ul><li><tt>environment.properties</tt> - This is the default configuration and will be packaged in the artifact by default.</li><li><tt>environment.test.properties</tt> - This is the variant for the test environment.</li><li><tt>environment.prod.properties</tt> - This is basically the same as the test variant and will be used in the production environment.<p>In the project descriptor, you need to configure the different profiles. Only the test profile is showed here.</p><div><pre> <profiles>
+ java/</pre></div></li></ul>
+<p>Under <tt>src/main/resources</tt> there are three files:</p>
+<ul>
+<li><tt>environment.properties</tt> - This is the default configuration and will be packaged in the artifact by default.</li>
+<li><tt>environment.test.properties</tt> - This is the variant for the test environment.</li>
+<li><tt>environment.prod.properties</tt> - This is basically the same as the test variant and will be used in the production environment.
+<p>In the project descriptor, you need to configure the different profiles. Only the test profile is showed here.</p>
+<div>
+<pre> <profiles>
<profile>
<id>test</id>
<build>
@@ -286,7 +303,25 @@ src/
.. Other profiles go here ..
- </profiles></pre></div><p>Three things are configured in this snippet:</p><ol style="list-style-type: decimal"><li>It configures the antrun plugin to execute the run goal in the test phase where it will copy the <tt>environment.test.properties</tt> file to <tt>environment.properties</tt>.</li><li>It will configure the test plugin to skip all tests when building the test and production artifacts. This is useful as you probably don't want to run tests against the production system</li><li>It configures the JAR plugin to create an "attached" JAR with the "test" classifier.<p>To activate this profile execute <tt>mvn -Ptest install</tt> and Maven will execute the steps in the profile in addition to the normal steps. From this build you will get two artifacts, "foo-1.0.jar" and "foo-1.0-test.jar". These two jars will identical. </p></li></ol></li></ul></div><div class="section"><h2>Caveats<a name="Caveats"></a></h2><ul><li>Currently M
aven 2 doesn't allow a project build to only produce attached artifacts. (i.e. it has to produce a "main" artifact as well) This results in two equal JARs being packaged and installed. The JAR plugin probably should also get improved support for this use case to that two different output directories will be used as the basis for building the JAR.</li><li>The usage of the delete task might seem a bit odd but is required to make sure that the copy task actually will copy the file. The copy task will look at the timestamps of the source and destination files, only when copying the files it won't know that the actually source file might be different than the last time it was executed.</li><li>After the build the test configuration will be in target/classes and won't be overridden because the resources plugin uses the same timestamp checking, so you should always do a clean after executing Maven with a profile.</li><li>For the reasons given above it's imperative that yo
u only build an artifact for a single environment in a single execution at a time and that you execute "mvn clean" whenever you change the profile switches. If not, you might get artifacts with a mixed set of configuration files.</li></ul></div><div class="section"><h2>Resources<a name="Resources"></a></h2><ol style="list-style-type: decimal"><li><a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a></li><li><a href="../introduction/introduction-to-the-standard-directory-layout.html">Standard Directory Layout</a></li></ol></div>
+ </profiles></pre></div>
+<p>Three things are configured in this snippet:</p>
+<ol style="list-style-type: decimal">
+<li>It configures the antrun plugin to execute the run goal in the test phase where it will copy the <tt>environment.test.properties</tt> file to <tt>environment.properties</tt>.</li>
+<li>It will configure the test plugin to skip all tests when building the test and production artifacts. This is useful as you probably don't want to run tests against the production system</li>
+<li>It configures the JAR plugin to create an "attached" JAR with the "test" classifier.
+<p>To activate this profile execute <tt>mvn -Ptest install</tt> and Maven will execute the steps in the profile in addition to the normal steps. From this build you will get two artifacts, "foo-1.0.jar" and "foo-1.0-test.jar". These two jars will identical. </p></li></ol></li></ul></div>
+<div class="section">
+<h2>Caveats<a name="Caveats"></a></h2>
+<ul>
+<li>Currently Maven 2 doesn't allow a project build to only produce attached artifacts. (i.e. it has to produce a "main" artifact as well) This results in two equal JARs being packaged and installed. The JAR plugin probably should also get improved support for this use case to that two different output directories will be used as the basis for building the JAR.</li>
+<li>The usage of the delete task might seem a bit odd but is required to make sure that the copy task actually will copy the file. The copy task will look at the timestamps of the source and destination files, only when copying the files it won't know that the actually source file might be different than the last time it was executed.</li>
+<li>After the build the test configuration will be in target/classes and won't be overridden because the resources plugin uses the same timestamp checking, so you should always do a clean after executing Maven with a profile.</li>
+<li>For the reasons given above it's imperative that you only build an artifact for a single environment in a single execution at a time and that you execute "mvn clean" whenever you change the profile switches. If not, you might get artifacts with a mixed set of configuration files.</li></ul></div>
+<div class="section">
+<h2>Resources<a name="Resources"></a></h2>
+<ol style="list-style-type: decimal">
+<li><a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a></li>
+<li><a href="../introduction/introduction-to-the-standard-directory-layout.html">Standard Directory Layout</a></li></ol></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/mini/guide-building-jdk14-on-jdk15.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-building-jdk14-on-jdk15.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-building-jdk14-on-jdk15.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -14,7 +14,7 @@
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="John Casey" />
<meta name="Date-Creation-yyyymmdd" content="20090802" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -44,7 +44,7 @@
Guide to Building JDK 1.4 Projects Using JDK 1.5
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -232,11 +232,28 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <!-- Licensed to the Apache Software Foundation (ASF) under one --><!-- or more contributor license agreements. See the NOTICE file --><!-- distributed with this work for additional information --><!-- regarding copyright ownership. The ASF licenses this file --><!-- to you under the Apache License, Version 2.0 (the --><!-- "License"); you may not use this file except in compliance --><!-- with the License. You may obtain a copy of the License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!-- --><!-- Unless required by applicable law or agreed to in writing, --><!-- software distributed under the License is distributed on an --><!-- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY --><!-- KIND, either express or implied. See the License for the --><!-- specific language governing permissions and limitations --><!-- under the License. --><!-- NOTE: For help with the syntax of this file, see: --><!-- http://maven.apache.org/doxia/referen
ces/apt-format.html --><div class="section"><h2>Guide to Building JDK 1.4 Projects Using JDK 1.5<a name="Guide_to_Building_JDK_1.4_Projects_Using_JDK_1.5"></a></h2><p>Since Maven 2.2.0 requires Java 1.5 to execute, users who still require their projects to run on Java 1.4 or older will need to make some adjustments.</p><p>Ideally, you could solve this problem by using JDK 1.4 to compile and test your project, by providing the appropriate <a href="./guide-using-toolchains.html">toolchains</a> configuration. However, the current release of the <a href="/plugins/maven-compiler-plugin">compiler plugin</a> (2.0.2) isn't toolchains-capable yet, so constructing a bullet-proof build using Maven 2.2.0 to target a Java platform older than 1.5 requires some more exotic configuration.</p><div class="section"><h3>First Step: <tt>Source</tt> and <tt>Target</tt> Configurations<a name="First_Step:_Source_and_Target_Configurations"></a></h3><p>The first step to supporting JDKs older than 1.5
in your build is already done for you: setting the <tt>source</tt> and <tt>target</tt> API versions in the configuration for the compiler plugin. Since JDK 1.5+ can still generate class files that are compliant with older JDKs, using this default compiler-plugin setting will render project artifacts that are technically compatible with JVMs older than 1.5.</p><p>This is great, until someone sneaks a <tt>String.contains( "foo" )</tt> into the codebase. If that happens, your project will still build successfully, and generate 1.4-compatible binaries. But try to execute your code in a 1.4 JVM, and you'll understand why the compiler configuration alone isn't enough. To construct a build process targeting JVM 1.4 when the build tool requires JVM 1.5+, while still ensuring the result of that build is safe to run on the 1.4 JVM, we need to use a tool that can verify the compatibility of our project code against a given Java API specification version.</p></div><div class=
"section"><h3>Enter the Animal Sniffer<a name="Enter_the_Animal_Sniffer"></a></h3><p>Fortunately, there is a project at dev.java.net called <a class="externalLink" href="https://animal-sniffer.dev.java.net/signature-checker.html">Animal Sniffer</a> that does exactly what we need. This project can verify the compatibility of a codebase against a whole range of Java APIs. Even better, it provides a Maven 2.x plugin to give users an easy way to integrate these checks into their build. To verify that your codebase complies with JDK 1.4 API, you simply tell the animal sniffer plugin to use:</p><div class="source"><pre><signature>
+ <!-- Licensed to the Apache Software Foundation (ASF) under one --><!-- or more contributor license agreements. See the NOTICE file --><!-- distributed with this work for additional information --><!-- regarding copyright ownership. The ASF licenses this file --><!-- to you under the Apache License, Version 2.0 (the --><!-- "License"); you may not use this file except in compliance --><!-- with the License. You may obtain a copy of the License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!-- --><!-- Unless required by applicable law or agreed to in writing, --><!-- software distributed under the License is distributed on an --><!-- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY --><!-- KIND, either express or implied. See the License for the --><!-- specific language governing permissions and limitations --><!-- under the License. --><!-- NOTE: For help with the syntax of this file, see: --><!-- http://maven.apache.org/doxia/referen
ces/apt-format.html --><div class="section">
+<h2>Guide to Building JDK 1.4 Projects Using JDK 1.5<a name="Guide_to_Building_JDK_1.4_Projects_Using_JDK_1.5"></a></h2>
+<p>Since Maven 2.2.0 requires Java 1.5 to execute, users who still require their projects to run on Java 1.4 or older will need to make some adjustments.</p>
+<p>Ideally, you could solve this problem by using JDK 1.4 to compile and test your project, by providing the appropriate <a href="./guide-using-toolchains.html">toolchains</a> configuration. However, the current release of the <a href="/plugins/maven-compiler-plugin">compiler plugin</a> (2.0.2) isn't toolchains-capable yet, so constructing a bullet-proof build using Maven 2.2.0 to target a Java platform older than 1.5 requires some more exotic configuration.</p>
+<div class="section">
+<h3>First Step: <tt>Source</tt> and <tt>Target</tt> Configurations<a name="First_Step:_Source_and_Target_Configurations"></a></h3>
+<p>The first step to supporting JDKs older than 1.5 in your build is already done for you: setting the <tt>source</tt> and <tt>target</tt> API versions in the configuration for the compiler plugin. Since JDK 1.5+ can still generate class files that are compliant with older JDKs, using this default compiler-plugin setting will render project artifacts that are technically compatible with JVMs older than 1.5.</p>
+<p>This is great, until someone sneaks a <tt>String.contains( "foo" )</tt> into the codebase. If that happens, your project will still build successfully, and generate 1.4-compatible binaries. But try to execute your code in a 1.4 JVM, and you'll understand why the compiler configuration alone isn't enough. To construct a build process targeting JVM 1.4 when the build tool requires JVM 1.5+, while still ensuring the result of that build is safe to run on the 1.4 JVM, we need to use a tool that can verify the compatibility of our project code against a given Java API specification version.</p></div>
+<div class="section">
+<h3>Enter the Animal Sniffer<a name="Enter_the_Animal_Sniffer"></a></h3>
+<p>Fortunately, there is a project at dev.java.net called <a class="externalLink" href="https://animal-sniffer.dev.java.net/signature-checker.html">Animal Sniffer</a> that does exactly what we need. This project can verify the compatibility of a codebase against a whole range of Java APIs. Even better, it provides a Maven 2.x plugin to give users an easy way to integrate these checks into their build. To verify that your codebase complies with JDK 1.4 API, you simply tell the animal sniffer plugin to use:</p>
+<div class="source">
+<pre><signature>
<groupId>org.jvnet.animal-sniffer</groupId>
<artifactId>java1.4</artifactId>
<version>1.0</version>
-</signature></pre></div></div><div class="section"><h3>Sample Configuration<a name="Sample_Configuration"></a></h3><p>Putting it all together, the following example shows how you can be certain your project will run on the 1.4 JVM:</p><div class="source"><pre><build>
+</signature></pre></div></div>
+<div class="section">
+<h3>Sample Configuration<a name="Sample_Configuration"></a></h3>
+<p>Putting it all together, the following example shows how you can be certain your project will run on the 1.4 JVM:</p>
+<div class="source">
+<pre><build>
<pluginManagement>
<plugins>
<plugin>
Modified: websites/staging/maven/trunk/content/guides/mini/guide-central-repository-upload.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-central-repository-upload.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-central-repository-upload.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -14,7 +14,7 @@
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Jason van Zyl
Brian Fox" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -44,7 +44,7 @@ Brian Fox" />
Guide to uploading artifacts to the Central Repository
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -232,7 +232,24 @@ Brian Fox" />
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Guide to uploading artifacts to the Central Repository<a name="Guide_to_uploading_artifacts_to_the_Central_Repository"></a></h2><p>In order for users of Maven to utilize artifacts produced by your project, you must deploy them to a remote repository. Many open source projects want to allow users of their projects who build with Maven to have transparent access to their project's artifacts. In order to allow for this, a project must have their artifacts deployed to the Central Repository.</p></div><div class="section"><h2><a name="Requirements">Requirements</a></h2><p>Only releases can be uploaded to the central repository, that means files that won't change and that only depend on other files already released and available in the repository.</p><p>There are some requirements for the minimal information in the POMs that are in the central repository. The updated list of requirements can be found <a class="externalLink" href="https://docs.sonat
ype.org/display/Repository/Central+Sync+Requirements">here</a>.</p></div><div class="section"><h2><a name="Choosing_your_coordinates">Choosing your coordinates</a></h2><p>Picking the appropriate coordinates for your project is important. See the guidelines <a class="externalLink" href="https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates">here</a>.</p><div class="section"><h3>Explanation<a name="Explanation"></a></h3><p>Some folks have asked why do we require all this information in the POM for deployed artifacts so here's a small explanation. The POM being deployed with the artifact is part of the process to make transitive dependencies a reality in Maven. The logic for getting transitive dependencies working is really not that hard, the problem is getting the data. The other applications that are made possible by having all the POMs available for artifacts are vast, so by placing them into the repository as part of the process we open up the doors to new
ideas that involve unified access to project POMs.</p><p>We also ask for license now because it is possible that your project's license may change in the course of its life time and we are trying create tools to help normal people sort out licensing issues. For example, knowing all the licenses for a particular graph of artifacts, we could have some strategies that would identify potential licensing problems.</p></div><div class="section"><h3>A basic sample:<a name="A_basic_sample:"></a></h3><div class="source"><pre>
+ <div class="section">
+<h2>Guide to uploading artifacts to the Central Repository<a name="Guide_to_uploading_artifacts_to_the_Central_Repository"></a></h2>
+<p>In order for users of Maven to utilize artifacts produced by your project, you must deploy them to a remote repository. Many open source projects want to allow users of their projects who build with Maven to have transparent access to their project's artifacts. In order to allow for this, a project must have their artifacts deployed to the Central Repository.</p></div>
+<div class="section">
+<h2><a name="Requirements">Requirements</a></h2>
+<p>Only releases can be uploaded to the central repository, that means files that won't change and that only depend on other files already released and available in the repository.</p>
+<p>There are some requirements for the minimal information in the POMs that are in the central repository. The updated list of requirements can be found <a class="externalLink" href="https://docs.sonatype.org/display/Repository/Central+Sync+Requirements">here</a>.</p></div>
+<div class="section">
+<h2><a name="Choosing_your_coordinates">Choosing your coordinates</a></h2>
+<p>Picking the appropriate coordinates for your project is important. See the guidelines <a class="externalLink" href="https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates">here</a>.</p>
+<div class="section">
+<h3>Explanation<a name="Explanation"></a></h3>
+<p>Some folks have asked why do we require all this information in the POM for deployed artifacts so here's a small explanation. The POM being deployed with the artifact is part of the process to make transitive dependencies a reality in Maven. The logic for getting transitive dependencies working is really not that hard, the problem is getting the data. The other applications that are made possible by having all the POMs available for artifacts are vast, so by placing them into the repository as part of the process we open up the doors to new ideas that involve unified access to project POMs.</p>
+<p>We also ask for license now because it is possible that your project's license may change in the course of its life time and we are trying create tools to help normal people sort out licensing issues. For example, knowing all the licenses for a particular graph of artifacts, we could have some strategies that would identify potential licensing problems.</p></div>
+<div class="section">
+<h3>A basic sample:<a name="A_basic_sample:"></a></h3>
+<div class="source">
+<pre>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache.maven</groupId>
@@ -271,7 +288,46 @@ Brian Fox" />
<pluginRepositories></pluginRepositories>
-->
</project>
-</pre></div></div><div class="section"><h3>PGP Signature<a name="PGP_Signature"></a></h3><p>When people download artifacts from Central Maven repository, they might want to validate that these artifacts have valid PGP signatures that can be verified against a public key server. If there is no signatures, then users have no guarantee that they are downloading the original artifact.</p><p>To improve the quality of the Central Maven repository, we require you to provide PGP signatures for all your artifacts (all files except checksums), and distribute your public key to a key server like <a class="externalLink" href="http://pgp.mit.edu">http://pgp.mit.edu</a>. Read <a class="externalLink" href="https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven">How to Generate PGP Signatures with Maven</a> for more information.</p></div><div class="section"><h3>FAQ and common mistakes<a name="FAQ_and_common_mistakes"></a></h3><ul><li>I have other <tt>reposit
ories</tt> or <tt>pluginRepositories</tt> listed in my POM, is that a problem?<p>At present, this won't preclude your project from being included, but we do strongly encourage making sure all your dependencies are included in Central. If you rely on sketchy repositories that have junk in them or disappear, it just creates havok for downstream users. Try to keep your dependencies among reliable repos like Central, Jboss, etc.</p></li><li>What about artifacts that can't be distributed because of their license?<p>In that case only the POM for that dependency is required, listing where the dependency can be downloaded from. <a class="externalLink" href="http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom">See an example</a>.</p></li><li>I have a patched version of the foo project developed at foo.com, what <tt>groupId</tt> should I use?<p>When you patch / modify a third party project, that patched version becomes your project and therefore
should be distributed under a <tt>groupId</tt> you control as any project you would have developed, never under <tt>com.foo</tt>. See above considerations about <tt>groupId</tt>.</p></li><li>My project is hosted at a project hosting service like SourceForge or dev.java.net, what should I use as groupId?<p>If your project name is <tt>foo</tt> at SourceForge, then <tt>net.sf.foo</tt>. If it's <tt>foo</tt> at dev.java.net, then <tt>net.java.dev.foo</tt></p></li></ul></div></div><div class="section"><h2><a name="Publishing_your_artifacts_to_the_Central_Repository">Publishing your artifacts to the Central Repository</a></h2><div class="section"><h3><a name="Approved_Repository_Hosting">Approved Repository Hosting</a></h3><p>Instead of maintaining repository rsync feeds for each projects, we now encourage projects to use an approved repository hosting location.</p><p>Currently approved repository hosting locations:</p><ul><li><a class="externalLink" href="http://www.apache.org/">A
pache Software Foundation</a> (for all Apache projects)</li><li><a class="externalLink" href="http://www.codehaus.org/">Codehaus</a> (for Codehaus projects)</li><li><a class="externalLink" href="http://www.fusesource.org/forge/">FuseSource Forge</a> (focused on FUSE related projects)</li><li><a class="externalLink" href="http://www.nuiton.org">Nuiton.org</a></li></ul><p>Automatic publication will be provided for Forges that provide hosting services for OSS projects and other large project repositories that meet certain minimum criteria such as validation of PGP keys and pom contents as defined above. If you are interested in becoming an approved Forge, contact us at <tt>repo-maintainers@maven.apache.org</tt>.</p></div><div class="section"><h3><a name="Other_Projects">Other Projects</a></h3><p>The easiest way to upload another project is to use the <a class="externalLink" href="http://nexus.sonatype.org/oss-repository-hosting.html">Sonatype OSS Repository</a>, which is an app
roved repository provided by Sonatype for <i>any</i> OSS Project that want to get their artifacts into Central Repository.</p><p>The service is proposed in two variants:</p><ul><li><a class="externalLink" href="https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide">Maven repository hosting service</a>: You can deploy snapshots, stage releases, and promote your releases so they will be published to Central Repository</li><li><a class="externalLink" href="https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central">Manual upload of artifacts</a>: The process is mostly automated with turnaround time averaging 1 business day.</li></ul></div><div class="section"><h3><a name="Explanations">Explanations</a></h3><p>Having each project maintain its own repository with rsync to Central Repository used to be the preferred process until January 2010. But we are no longer accepting rsync requests on a per project basis.</p>
<p>Over time, we have learned that this process is not scalable. Many of the projects being synced release very infrequently, yet we have to hit hundreds of servers several times a day looking for artifacts that don't change. Additionally, there is no good mechanism currently for validating the incoming data via the rsync, and this leads to bad metadata that affects everyone. </p><p>The aggregation of projects into single larger feeds allows us to sync faster and more often, and ensuring these locations perform sufficient checks increases the quality of metadata for everyone.</p></div></div>
+</pre></div></div>
+<div class="section">
+<h3>PGP Signature<a name="PGP_Signature"></a></h3>
+<p>When people download artifacts from Central Maven repository, they might want to validate that these artifacts have valid PGP signatures that can be verified against a public key server. If there is no signatures, then users have no guarantee that they are downloading the original artifact.</p>
+<p>To improve the quality of the Central Maven repository, we require you to provide PGP signatures for all your artifacts (all files except checksums), and distribute your public key to a key server like <a class="externalLink" href="http://pgp.mit.edu">http://pgp.mit.edu</a>. Read <a class="externalLink" href="https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven">How to Generate PGP Signatures with Maven</a> for more information.</p></div>
+<div class="section">
+<h3>FAQ and common mistakes<a name="FAQ_and_common_mistakes"></a></h3>
+<ul>
+<li>I have other <tt>repositories</tt> or <tt>pluginRepositories</tt> listed in my POM, is that a problem?
+<p>At present, this won't preclude your project from being included, but we do strongly encourage making sure all your dependencies are included in Central. If you rely on sketchy repositories that have junk in them or disappear, it just creates havok for downstream users. Try to keep your dependencies among reliable repos like Central, Jboss, etc.</p></li>
+<li>What about artifacts that can't be distributed because of their license?
+<p>In that case only the POM for that dependency is required, listing where the dependency can be downloaded from. <a class="externalLink" href="http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom">See an example</a>.</p></li>
+<li>I have a patched version of the foo project developed at foo.com, what <tt>groupId</tt> should I use?
+<p>When you patch / modify a third party project, that patched version becomes your project and therefore should be distributed under a <tt>groupId</tt> you control as any project you would have developed, never under <tt>com.foo</tt>. See above considerations about <tt>groupId</tt>.</p></li>
+<li>My project is hosted at a project hosting service like SourceForge or dev.java.net, what should I use as groupId?
+<p>If your project name is <tt>foo</tt> at SourceForge, then <tt>net.sf.foo</tt>. If it's <tt>foo</tt> at dev.java.net, then <tt>net.java.dev.foo</tt></p></li></ul></div></div>
+<div class="section">
+<h2><a name="Publishing_your_artifacts_to_the_Central_Repository">Publishing your artifacts to the Central Repository</a></h2>
+<div class="section">
+<h3><a name="Approved_Repository_Hosting">Approved Repository Hosting</a></h3>
+<p>Instead of maintaining repository rsync feeds for each projects, we now encourage projects to use an approved repository hosting location.</p>
+<p>Currently approved repository hosting locations:</p>
+<ul>
+<li><a class="externalLink" href="http://www.apache.org/">Apache Software Foundation</a> (for all Apache projects)</li>
+<li><a class="externalLink" href="http://www.codehaus.org/">Codehaus</a> (for Codehaus projects)</li>
+<li><a class="externalLink" href="http://www.fusesource.org/forge/">FuseSource Forge</a> (focused on FUSE related projects)</li>
+<li><a class="externalLink" href="http://www.nuiton.org">Nuiton.org</a></li></ul>
+<p>Automatic publication will be provided for Forges that provide hosting services for OSS projects and other large project repositories that meet certain minimum criteria such as validation of PGP keys and pom contents as defined above. If you are interested in becoming an approved Forge, contact us at <tt>repo-maintainers@maven.apache.org</tt>.</p></div>
+<div class="section">
+<h3><a name="Other_Projects">Other Projects</a></h3>
+<p>The easiest way to upload another project is to use the <a class="externalLink" href="http://nexus.sonatype.org/oss-repository-hosting.html">Sonatype OSS Repository</a>, which is an approved repository provided by Sonatype for <i>any</i> OSS Project that want to get their artifacts into Central Repository.</p>
+<p>The service is proposed in two variants:</p>
+<ul>
+<li><a class="externalLink" href="https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide">Maven repository hosting service</a>: You can deploy snapshots, stage releases, and promote your releases so they will be published to Central Repository</li>
+<li><a class="externalLink" href="https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central">Manual upload of artifacts</a>: The process is mostly automated with turnaround time averaging 1 business day.</li></ul></div>
+<div class="section">
+<h3><a name="Explanations">Explanations</a></h3>
+<p>Having each project maintain its own repository with rsync to Central Repository used to be the preferred process until January 2010. But we are no longer accepting rsync requests on a per project basis.</p>
+<p>Over time, we have learned that this process is not scalable. Many of the projects being synced release very infrequently, yet we have to hit hundreds of servers several times a day looking for artifacts that don't change. Additionally, there is no good mechanism currently for validating the incoming data via the rsync, and this leads to bad metadata that affects everyone. </p>
+<p>The aggregation of projects into single larger feeds allows us to sync faster and more often, and ensuring these locations perform sufficient checks increases the quality of metadata for everyone.</p></div></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/mini/guide-configuring-maven.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/mini/guide-configuring-maven.html (original)
+++ websites/staging/maven/trunk/content/guides/mini/guide-configuring-maven.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Brett Porter" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Guide to Configuring Maven
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,11 +231,46 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Configuring Maven<a name="Configuring_Maven"></a></h2><p>Maven configuration occurs at 3 levels:</p><ul><li><i>Project</i> - most static configuration occurs in <tt>pom.xml</tt></li><li><i>Installation</i> - this is configuration added once for a Maven installation</li><li><i>User</i> - this is configuration specific to a particular user</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><b>Note:</b> the installation and user configuration cannot be used to add shared project information - for example, setting <tt><organization></tt> or <tt><distributionManagement></tt> company-wide.</p><p>For this, you should have your projects inherit from a company-wide parent <tt>pom.xml</tt>.</p><!-- TODO: versioning doc that discusses this --><p>You can specify your user configuration in
<tt>${user.home}/.m2/settings.xml</tt>. 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><div class="section"><h3>Configuring your Local Repository<a name="Configuring_your_Local_Repository"></a></h3><p>The location of your local repository can be changed in your user configuration. The default value is <tt>${user.home}/.m2/repository/</tt>.</p><div><pre><settings>
+ <div class="section">
+<h2>Configuring Maven<a name="Configuring_Maven"></a></h2>
+<p>Maven configuration occurs at 3 levels:</p>
+<ul>
+<li><i>Project</i> - most static configuration occurs in <tt>pom.xml</tt></li>
+<li><i>Installation</i> - this is configuration added once for a Maven installation</li>
+<li><i>User</i> - this is configuration specific to a particular user</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><b>Note:</b> the installation and user configuration cannot be used to add shared project information - for example, setting <tt><organization></tt> or <tt><distributionManagement></tt> company-wide.</p>
+<p>For this, you should have your projects inherit from a company-wide parent <tt>pom.xml</tt>.</p><!-- TODO: versioning doc that discusses this -->
+<p>You can specify your user configuration in <tt>${user.home}/.m2/settings.xml</tt>. 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>
+<div class="section">
+<h3>Configuring your Local Repository<a name="Configuring_your_Local_Repository"></a></h3>
+<p>The location of your local repository can be changed in your user configuration. The default value is <tt>${user.home}/.m2/repository/</tt>.</p>
+<div>
+<pre><settings>
...
<localRepository>/path/to/local/repo/</localRepository>
...
-</settings></pre></div><p><b>Note:</b> The local repository must be an absolute path.</p></div><div class="section"><h3>Configuring a Proxy<a name="Configuring_a_Proxy"></a></h3><p>Proxy configuration can also be specified in the settings file.</p><p>For more information, see the <a href="./guide-proxies.html"> Guide to using a Proxy</a>.</p></div><div class="section"><h3>Configuring Parallel Artifact Resolution<a name="Configuring_Parallel_Artifact_Resolution"></a></h3><p>By default, Maven 2.1.0+ will download up to 5 artifacts (from different groups) at once. To change the size of the thread pool, start Maven using <tt>-Dmaven.artifact.threads</tt>. For example, to only download single artifacts at a time:</p><div><pre>mvn -Dmaven.artifact.threads=1 clean install</pre></div><p>You may wish to set this option permanently, in which case you can use the <tt>MAVEN_OPTS</tt> environment variable. For example:</p><div><pre>export MAVEN_OPTS=-Dmaven.artifact.threads=3</pre>
</div></div><div class="section"><h3>Security and Deployment Settings<a name="Security_and_Deployment_Settings"></a></h3><p>Repositories to deploy to are defined in a project in the <tt><distributionManagement></tt> 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 <tt>id</tt> 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 <tt>server</tt> 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><div><pre><settings>
+</settings></pre></div>
+<p><b>Note:</b> The local repository must be an absolute path.</p></div>
+<div class="section">
+<h3>Configuring a Proxy<a name="Configuring_a_Proxy"></a></h3>
+<p>Proxy configuration can also be specified in the settings file.</p>
+<p>For more information, see the <a href="./guide-proxies.html"> Guide to using a Proxy</a>.</p></div>
+<div class="section">
+<h3>Configuring Parallel Artifact Resolution<a name="Configuring_Parallel_Artifact_Resolution"></a></h3>
+<p>By default, Maven 2.1.0+ will download up to 5 artifacts (from different groups) at once. To change the size of the thread pool, start Maven using <tt>-Dmaven.artifact.threads</tt>. For example, to only download single artifacts at a time:</p>
+<div>
+<pre>mvn -Dmaven.artifact.threads=1 clean install</pre></div>
+<p>You may wish to set this option permanently, in which case you can use the <tt>MAVEN_OPTS</tt> environment variable. For example:</p>
+<div>
+<pre>export MAVEN_OPTS=-Dmaven.artifact.threads=3</pre></div></div>
+<div class="section">
+<h3>Security and Deployment Settings<a name="Security_and_Deployment_Settings"></a></h3>
+<p>Repositories to deploy to are defined in a project in the <tt><distributionManagement></tt> 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 <tt>id</tt> 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 <tt>server</tt> 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>
+<div>
+<pre><settings>
...
<servers>
<server>
@@ -250,7 +285,14 @@
...
</servers>
...
-</settings></pre></div><p>To encrypt passwords in these sections, refer to <a href="./guide-encryption.html"> Encryption Settings</a>.</p></div><div class="section"><h3>Using Mirrors for Repositories<a name="Using_Mirrors_for_Repositories"></a></h3><p>Repositories can be declared inside a project, which means that if you have your own custom repositories, those sharing your project easily get the right settings out of the box. However, you may want to use an alternative mirror for a particular repository without changing the project files. Refer to <a href="./guide-mirror-settings.html"> Guide to Mirror Settings</a> for more details.</p></div><div class="section"><h3>Profiles<a name="Profiles"></a></h3><p>Repository configuration can also be put into a profile. You can have multiple profiles, with one set to active so that you can easily switch environments. Read more about profiles in <a href="../introduction/introduction-to-profiles.html">Introduction to Build Profil
es</a>.</p></div></div>
+</settings></pre></div>
+<p>To encrypt passwords in these sections, refer to <a href="./guide-encryption.html"> Encryption Settings</a>.</p></div>
+<div class="section">
+<h3>Using Mirrors for Repositories<a name="Using_Mirrors_for_Repositories"></a></h3>
+<p>Repositories can be declared inside a project, which means that if you have your own custom repositories, those sharing your project easily get the right settings out of the box. However, you may want to use an alternative mirror for a particular repository without changing the project files. Refer to <a href="./guide-mirror-settings.html"> Guide to Mirror Settings</a> for more details.</p></div>
+<div class="section">
+<h3>Profiles<a name="Profiles"></a></h3>
+<p>Repository configuration can also be put into a profile. You can have multiple profiles, with one set to active so that you can easily switch environments. Read more about profiles in <a href="../introduction/introduction-to-profiles.html">Introduction to Build Profiles</a>.</p></div></div>
</div>
</div>
<div class="clear">