You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-commits@maven.apache.org by sv...@apache.org on 2023/10/04 17:31:59 UTC
svn commit: r1912733 - in /maven/website/content: ./ guides/getting-started/ guides/mini/ plugin-developers/ plugin-developers/cookbook/
Author: svn-site-role
Date: Wed Oct 4 17:31:58 2023
New Revision: 1912733
Log:
Site checkin for project Apache Maven Site
Modified:
maven/website/content/faq-unoffical.html
maven/website/content/guides/getting-started/index.html
maven/website/content/guides/mini/guide-attached-tests.html
maven/website/content/guides/mini/guide-site.html
maven/website/content/guides/mini/guide-snippet-macro.html
maven/website/content/maven-site-1.0-site.jar
maven/website/content/plugin-developers/common-bugs.html
maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html
maven/website/content/pom.html
Modified: maven/website/content/faq-unoffical.html
==============================================================================
--- maven/website/content/faq-unoffical.html (original)
+++ maven/website/content/faq-unoffical.html Wed Oct 4 17:31:58 2023
@@ -989,7 +989,7 @@ NOTE: this may only work in the latest p
<path refid="maven.compile.classpath"/>
<path refid="maven.plugin.classpath"/>
</path>
- <ant antfile="${basedir}/build.xml" dir="${basedir}" inheritRefs="true">
+ <ant antfile="${project.basedir}/build.xml" dir="${project.basedir}" inheritRefs="true">
<target name="generate-sources"/>
</ant>
</tasks>
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 Wed Oct 4 17:31:58 2023
@@ -260,7 +260,7 @@
`-- mycompany
`-- app
`-- AppTest.java</pre></div>
-<p>As you can see, the project created from the archetype has a POM, a source tree for your application's sources and a source tree for your test sources. This is the standard layout for Maven projects (the application sources reside in <code>${basedir}/src/main/java</code> and test sources reside in <code>${basedir}/src/test/java</code>, where ${basedir} represents the directory containing <code>pom.xml</code>).</p>
+<p>As you can see, the project created from the archetype has a POM, a source tree for your application's sources and a source tree for your test sources. This is the standard layout for Maven projects (the application sources reside in <code>${project.basedir}/src/main/java</code> and test sources reside in <code>${project.basedir}/src/test/java</code>, where ${project.basedir} represents the directory containing <code>pom.xml</code>).</p>
<p>If you were to create a Maven project by hand this is the directory structure that we recommend using. This is a Maven convention and to learn more about it you can read our <a href="../introduction/introduction-to-the-standard-directory-layout.html">Introduction to the Standard Directory Layout</a>.</p>
<p>Now that we have a POM, some application sources, and some test sources you are probably asking...</p></section><section>
<h2><a id="How_do_I_compile_my_application_sources.3F">How do I compile my application sources?</a></h2>
@@ -289,7 +289,7 @@
[INFO] Finished at: 2020-07-12T11:31:54+01:00
[INFO] ------------------------------------------------------------------------</pre></div>
<p>The first time you execute this (or any other) command, Maven will need to download all the plugins and related dependencies it needs to fulfill the command. From a clean installation of Maven, this can take quite a while (in the output above, it took almost 4 minutes). If you execute the command again, Maven will now have what it needs, so it won't need to download anything new and will be able to execute the command much more quickly.</p>
-<p>As you can see from the output, the compiled classes were placed in <code>${basedir}/target/classes</code>, which is another standard convention employed by Maven. So, if you're a keen observer, you'll notice that by using the standard conventions, the POM above is very small and you haven't had to tell Maven explicitly where any of your sources are or where the output should go. By following the standard Maven conventions, you can get a lot done with very little effort! Just as a casual comparison, let's take a look at what you might have had to do in <a class="externalLink" href="http://ant.apache.org">Ant</a> to accomplish the same <a href="../../ant/build-a1.xml">thing</a>.</p>
+<p>As you can see from the output, the compiled classes were placed in <code>${project.basedir}/target/classes</code>, which is another standard convention employed by Maven. So, if you're a keen observer, you'll notice that by using the standard conventions, the POM above is very small and you haven't had to tell Maven explicitly where any of your sources are or where the output should go. By following the standard Maven conventions, you can get a lot done with very little effort! Just as a casual comparison, let's take a look at what you might have had to do in <a class="externalLink" href="http://ant.apache.org">Ant</a> to accomplish the same <a href="../../ant/build-a1.xml">thing</a>.</p>
<p>Now, this is simply to compile a single tree of application sources and the Ant script shown is pretty much the same size as the POM shown above. But we'll see how much more we can do with just that simple POM!</p></section><section>
<h2><a id="How_do_I_compile_my_test_sources_and_run_my_unit_tests.3F">How do I compile my test sources and run my unit tests?</a></h2>
<p>Now you're successfully compiling your application's sources and now you've got some unit tests that you want to compile and execute (because every programmer always writes and executes their unit tests *nudge nudge wink wink*).</p>
@@ -349,7 +349,7 @@
<p>Making a JAR file is straight forward enough and can be accomplished by executing the following command:</p>
<div class="verbatim">
<pre>mvn package</pre></div>
-<p>You can now take a look in the <code>${basedir}/target</code> directory and you will see the generated JAR file.</p>
+<p>You can now take a look in the <code>${project.basedir}/target</code> directory and you will see the generated JAR file.</p>
<p>Now you'll want to install the artifact you've generated (the JAR file) in your local repository (<code>${user.home}/.m2/repository</code> is the default location). For more information on repositories you can refer to our <a href="../introduction/introduction-to-repositories.html">Introduction to Repositories</a> but let's move on to installing our artifact! To do so execute the following command:</p>
<div class="verbatim">
<pre>mvn install</pre></div>
@@ -449,7 +449,7 @@
<p>To find out what configuration is available for a plugin, you can see the <a href="../../plugins/"> Plugins List</a> and navigate to the plugin and goal you are using. For general information about how to configure the available parameters of a plugin, have a look at the <a href="../mini/guide-configuring-plugins.html">Guide to Configuring Plugins</a>.</p></section><section>
<h2><a id="How_do_I_add_resources_to_my_JAR.3F">How do I add resources to my JAR?</a></h2>
<p>Another common use case that can be satisfied which requires no changes to the POM that we have above is packaging resources in the JAR file. For this common task, Maven again relies on the <a href="../introduction/introduction-to-the-standard-directory-layout.html">Standard Directory Layout</a>, which means by using standard Maven conventions you can package resources within JARs simply by placing those resources in a standard directory structure.</p>
-<p>You see below in our example we have added the directory <code>${basedir}/src/main/resources</code> into which we place any resources we wish to package in our JAR. The simple rule employed by Maven is this: any directories or files placed within the <code>${basedir}/src/main/resources</code> directory are packaged in your JAR with the exact same structure starting at the base of the JAR.</p>
+<p>You see below in our example we have added the directory <code>${project.basedir}/src/main/resources</code> into which we place any resources we wish to package in our JAR. The simple rule employed by Maven is this: any directories or files placed within the <code>${project.basedir}/src/main/resources</code> directory are packaged in your JAR with the exact same structure starting at the base of the JAR.</p>
<div class="verbatim">
<pre>my-app
|-- pom.xml
@@ -483,14 +483,14 @@
`-- mycompany
`-- app
`-- App.class</pre></div>
-<p>As you can see, the contents of <code>${basedir}/src/main/resources</code> can be found starting at the base of the JAR and our <code>application.properties</code> file is there in the <code>META-INF</code> directory. You will also notice some other files there like <code>META-INF/MANIFEST.MF</code> as well as a <code>pom.xml</code> and <code>pom.properties</code> file. These come standard with generation of a JAR in Maven. You can create your own manifest if you choose, but Maven will generate one by default if you don't. (You can also modify the entries in the default manifest. We will touch on this later.) The <code>pom.xml</code> and <code>pom.properties</code> files are packaged up in the JAR so that each artifact produced by Maven is self-describing and also allows you to utilize the metadata in your own application if the need arises. One simple use might be to retrieve the version of your application. Operating on the POM file would require you to use some Maven utilities
but the properties can be utilized using the standard Java API and look like the following:</p>
+<p>As you can see, the contents of <code>${project.basedir}/src/main/resources</code> can be found starting at the base of the JAR and our <code>application.properties</code> file is there in the <code>META-INF</code> directory. You will also notice some other files there like <code>META-INF/MANIFEST.MF</code> as well as a <code>pom.xml</code> and <code>pom.properties</code> file. These come standard with generation of a JAR in Maven. You can create your own manifest if you choose, but Maven will generate one by default if you don't. (You can also modify the entries in the default manifest. We will touch on this later.) The <code>pom.xml</code> and <code>pom.properties</code> files are packaged up in the JAR so that each artifact produced by Maven is self-describing and also allows you to utilize the metadata in your own application if the need arises. One simple use might be to retrieve the version of your application. Operating on the POM file would require you to use some Maven u
tilities but the properties can be utilized using the standard Java API and look like the following:</p>
<div class="verbatim">
<pre>#Generated by Maven
#Tue Oct 04 15:43:21 GMT-05:00 2005
version=1.0-SNAPSHOT
groupId=com.mycompany.app
artifactId=my-app</pre></div>
-<p>To add resources to the classpath for your unit tests, you follow the same pattern as you do for adding resources to the JAR except the directory you place resources in is ${basedir}/src/test/resources. At this point you would have a project directory structure that would look like the following:</p>
+<p>To add resources to the classpath for your unit tests, you follow the same pattern as you do for adding resources to the JAR except the directory you place resources in is ${project.basedir}/src/test/resources. At this point you would have a project directory structure that would look like the following:</p>
<div class="verbatim">
<pre>my-app
|-- pom.xml
Modified: maven/website/content/guides/mini/guide-attached-tests.html
==============================================================================
--- maven/website/content/guides/mini/guide-attached-tests.html (original)
+++ maven/website/content/guides/mini/guide-attached-tests.html Wed Oct 4 17:31:58 2023
@@ -130,7 +130,7 @@
<main id="bodyColumn" class="span10" >
<section>
<h1>Guide to using attached tests</h1>
-<p>You can reuse the tests that you have created for one project in another. For example, suppose <code>foo-core</code> contains test code in the <code>${basedir}/src/test/java</code>. To package up those compiled tests in a JAR and deploy them for general reuse, configure the <code>maven-jar-plugin</code> as follows:</p>
+<p>You can reuse the tests that you have created for one project in another. For example, suppose <code>foo-core</code> contains test code in the <code>${project.basedir}/src/test/java</code>. To package up those compiled tests in a JAR and deploy them for general reuse, configure the <code>maven-jar-plugin</code> as follows:</p>
<div class="verbatim source"><pre class="prettyprint linenums">
<project>
<build>
Modified: maven/website/content/guides/mini/guide-site.html
==============================================================================
--- maven/website/content/guides/mini/guide-site.html (original)
+++ maven/website/content/guides/mini/guide-site.html Wed Oct 4 17:31:58 2023
@@ -169,7 +169,7 @@
| +- other.xml
|
+- site.xml</pre></div>
-<p>You will notice there is now a <code>${basedir}/src/site</code> directory within which is contained a <code>site.xml</code> site descriptor along with various directories corresponding to the supported document types.</p>
+<p>You will notice there is now a <code>${project.basedir}/src/site</code> directory within which is contained a <code>site.xml</code> site descriptor along with various directories corresponding to the supported document types.</p>
<p>Let's take a look at the examples of the various document types:</p>
<ul>
<li><code>apt</code>: the APT format, "Almost Plain Text", is a wiki-like format that allows you to write simple, structured documents (like this one) very quickly. A full reference of the <a href="/doxia/references/apt-format.html">APT Format</a> is available,</li>
Modified: maven/website/content/guides/mini/guide-snippet-macro.html
==============================================================================
--- maven/website/content/guides/mini/guide-snippet-macro.html (original)
+++ maven/website/content/guides/mini/guide-snippet-macro.html Wed Oct 4 17:31:58 2023
@@ -185,7 +185,7 @@
<div class="verbatim source"><pre class="prettyprint linenums"> %{snippet|id=snip-id|url=http://svn.example.com/path/to/Sample.java}
%{snippet|id=snip-id|url=file:///path/to/Sample.java}</pre></div>
-<p>As of doxia-core version 1.0-alpha-9, a 'file' parameter is also available. If a full path is not specified, the location is assumed to be relative to ${basedir}.</p>
+<p>As of doxia-core version 1.0-alpha-9, a 'file' parameter is also available. If a full path is not specified, the location is assumed to be relative to ${project.basedir}.</p>
<div class="verbatim source"><pre class="prettyprint linenums"> ~~ Since doxia-core 1.0-alpha-9
%{snippet|id=abc|file=src/main/webapp/index.jsp}</pre></div>
<ul>
Modified: maven/website/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.
Modified: maven/website/content/plugin-developers/common-bugs.html
==============================================================================
--- maven/website/content/plugin-developers/common-bugs.html (original)
+++ maven/website/content/plugin-developers/common-bugs.html Wed Oct 4 17:31:58 2023
@@ -262,7 +262,7 @@ if ( "info".equals( debugLevel
<p>The problem is that the JVM executing Maven can be running much longer than the actual Maven build. Of course, this does not apply to the standalone invocation of Maven from the command line. However, it affects the embedded usage of Maven in IDEs or CI servers. In those cases, the cleanup tasks will be deferred, too. If the JVM is then executing a bunch of other Maven builds, many such cleanup tasks can sum up, eating up resources of the JVM.</p>
<p>For this reason, plugin developers should avoid usage of shutdown hooks and rather use <code>try</code>/<code>finally</code> blocks to perform cleanup as soon as the resources are no longer needed.</p></section><section>
<h2><a id="Resolving_Relative_Paths">Resolving Relative Paths</a></h2>
-<p>It is common practice for users of Maven to specify relative paths in the POM, not to mention that the Super POM does so, too. The intention is to resolve such relative paths against the base directory of the current project. In other words, the paths <code>target/classes</code> and <code>${basedir}/target/classes</code> should resolve to the same directory for a given POM.</p>
+<p>It is common practice for users of Maven to specify relative paths in the POM, not to mention that the Super POM does so, too. The intention is to resolve such relative paths against the base directory of the current project. In other words, the paths <code>target/classes</code> and <code>${project.basedir}/target/classes</code> should resolve to the same directory for a given POM.</p>
<p>Unfortunately, the class <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/io/File.html">java.io.File</a></code> does not resolve relative paths against the project's base directory. As mentioned in its class javadoc, it resolves relative paths against the current working directory. In plain English: Unless a Maven component has complete control over the current working directory, any usage of <code>java.io.File</code> in combination with a relative path is a bug.</p>
<p>At first glance, one might be tempted to argue that the project base directory is equal to the current working directory. However, this assumption is generally not true. Consider the following scenarios:</p>
<ol style="list-style-type: lower-alpha">
Modified: maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html
==============================================================================
--- maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html (original)
+++ maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html Wed Oct 4 17:31:58 2023
@@ -187,7 +187,7 @@
<tr class="b">
<td style="text-align: center;"></td>
<td style="text-align: center;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-maven-plugin/merge-descriptors-mojo.html"><code>merge-descriptors</code></a></td>
-<td style="text-align: center;">see <code>staticMetadataDirectory</code> parameter  <br />default: <code>${basedir}/src/main/resources/META-INF/plexus</code></td></tr>
+<td style="text-align: center;">see <code>staticMetadataDirectory</code> parameter  <br />default: <code>${project.basedir}/src/main/resources/META-INF/plexus</code></td></tr>
<tr class="a">
<td style="text-align: center;"></td>
<td style="text-align: center;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-maven-plugin/test-descriptor-mojo.html"><code>test-descriptor</code></a></td>
@@ -195,7 +195,7 @@
<tr class="b">
<td style="text-align: center;"></td>
<td style="text-align: center;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-maven-plugin/test-merge-descriptors-mojo.html"><code>test-merge-descriptors</code></a></td>
-<td style="text-align: center;">see <code>testStaticMetadataDirectory</code> parameter  <br />default: <code>${basedir}/src/test/resources/META-INF/plexus</code></td></tr>
+<td style="text-align: center;">see <code>testStaticMetadataDirectory</code> parameter  <br />default: <code>${project.basedir}/src/test/resources/META-INF/plexus</code></td></tr>
<tr class="a">
<td style="text-align: center;"></td>
<td style="text-align: center;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-maven-plugin/components-report-mojo.html"><code>components-report</code></a></td>
@@ -242,7 +242,7 @@
</plugin>
</build>
</project></pre></div>
-<p>If <code>merge-descriptors</code> is used, move the handwritten xml file to <code>${basedir}/src/main/resources/META-INF/plexus</code>.</p></section><section>
+<p>If <code>merge-descriptors</code> is used, move the handwritten xml file to <code>${project.basedir}/src/main/resources/META-INF/plexus</code>.</p></section><section>
<h3>Replacing Plexus Javadoc Tags with Plexus Java 5 Annotations</h3>
<p>In your <code>pom.xml</code>, add <code>plexus-component-annotations</code> dependency:</p>
<div class="verbatim source"><pre class="prettyprint linenums"><project>
Modified: maven/website/content/pom.html
==============================================================================
--- maven/website/content/pom.html (original)
+++ maven/website/content/pom.html Wed Oct 4 17:31:58 2023
@@ -698,7 +698,7 @@ Display parameters as parsed by Maven (i
<div class="verbatim">
<pre><build>
<defaultGoal>install</defaultGoal>
- <directory>${basedir}/target</directory>
+ <directory>/home/jenkins/82467a7c/workspace/aven_maven-box_maven-site_master/target</directory>
<finalName>${artifactId}-${version}</finalName>
<filters>
<filter>filters/filter1.properties</filter>
@@ -707,9 +707,9 @@ Display parameters as parsed by Maven (i
</build></pre></div>
<ul>
<li><b>defaultGoal</b>: the default goal or phase to execute if none is given. If a goal is given, it should be defined as it is in the command line (such as <code>jar:jar</code>). The same goes for if a phase is defined (such as install).</li>
-<li><b>directory</b>: This is the directory where the build will dump its files or, in Maven parlance, the build's target. It aptly defaults to <code>${basedir}/target</code>.</li>
+<li><b>directory</b>: This is the directory where the build will dump its files or, in Maven parlance, the build's target. It aptly defaults to <code>${project.basedir}/target</code>.</li>
<li><b>finalName</b>: This is the name of the bundled project when it is finally built (sans the file extension, for example: <code>my-project-1.0.jar</code>). It defaults to <code>${artifactId}-${version}</code>. The term "finalName" is kind of a misnomer, however, as plugins that build the bundled project have every right to ignore/modify this name (but they usually do not). For example, if the <code>maven-jar-plugin</code> is configured to give a jar a <code>classifier</code> of <code>test</code>, then the actual jar defined above will be built as <code>my-project-1.0-test.jar</code>.</li>
-<li><b>filter</b>: Defines <code>*.properties</code> files that contain a list of properties that apply to resources which accept their settings (covered below). In other words, the "<code>name=value</code>" pairs defined within the filter files replace <code>${name}</code> strings within resources on build. The example above defines the <code>filter1.properties</code> file under the <code>filters/</code> directory. Maven's default filter directory is <code>${basedir}/src/main/filters/</code>.
+<li><b>filter</b>: Defines <code>*.properties</code> files that contain a list of properties that apply to resources which accept their settings (covered below). In other words, the "<code>name=value</code>" pairs defined within the filter files replace <code>${name}</code> strings within resources on build. The example above defines the <code>filter1.properties</code> file under the <code>filters/</code> directory. Maven's default filter directory is <code>${project.basedir}/src/main/filters/</code>.
<p>For a more comprehensive look at what filters are and what they can do, take a look at the <a href="./guides/getting-started">quick start guide</a>.</p></li></ul><section>
<h4><a id="Resources">Resources</a></h4>
<p>Another feature of <code>build</code> elements is specifying where resources exist within your project. Resources are not (usually) code. They are not compiled, but are items meant to be bundled within your project or used for various other reasons, such as code generation.</p>
@@ -722,7 +722,7 @@ Display parameters as parsed by Maven (i
<resource>
<targetPath>META-INF/plexus</targetPath>
<filtering>false</filtering>
- <directory>${basedir}/src/main/plexus</directory>
+ <directory>/home/jenkins/82467a7c/workspace/aven_maven-box_maven-site_master/src/main/plexus</directory>
<includes>
<include>configuration.xml</include>
</includes>
@@ -741,10 +741,10 @@ Display parameters as parsed by Maven (i
<li><b>resources</b>: is a list of resource elements that each describe what and where to include files associated with this project.</li>
<li><b>targetPath</b>: Specifies the directory structure to place the set of resources from a build. Target path defaults to the base directory. A commonly specified target path for resources that will be packaged in a JAR is META-INF.</li>
<li><b>filtering</b>: is <code>true</code> or <code>false</code>, denoting if filtering is to be enabled for this resource. Note, that filter <code>*.properties</code> files do not have to be defined for filtering to occur - resources can also use properties that are by default defined in the POM (such as ${project.version}), passed into the command line using the "-D" flag (for example, "<code>-Dname</code>=<code>value</code>") or are explicitly defined by the properties element. Filter files were covered above.</li>
-<li><b>directory</b>: This element's value defines where the resources are to be found. The default directory for a build is <code>${basedir}/src/main/resources</code>.</li>
+<li><b>directory</b>: This element's value defines where the resources are to be found. The default directory for a build is <code>${project.basedir}/src/main/resources</code>.</li>
<li><b>includes</b>: A set of files patterns which specify the files to include as resources under that specified directory, using * as a wildcard.</li>
<li><b>excludes</b>: The same structure as <code>includes</code>, but specifies which files to ignore. In conflicts between <code>include</code> and <code>exclude</code>, <code>exclude</code> wins.</li>
-<li><b>testResources</b>: The <code>testResources</code> element block contains <code>testResource</code> elements. Their definitions are similar to <code>resource</code> elements, but are naturally used during test phases. The one difference is that the default (Super POM defined) test resource directory for a project is <code>${basedir}/src/test/resources</code>. Test resources are not deployed.</li></ul></section><section>
+<li><b>testResources</b>: The <code>testResources</code> element block contains <code>testResource</code> elements. Their definitions are similar to <code>resource</code> elements, but are naturally used during test phases. The one difference is that the default (Super POM defined) test resource directory for a project is <code>${project.basedir}/src/test/resources</code>. Test resources are not deployed.</li></ul></section><section>
<h4><a id="Plugins">Plugins</a></h4>
<div class="verbatim 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -935,15 +935,15 @@ Display parameters as parsed by Maven (i
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
<build>
- <sourceDirectory>${basedir}/src/main/java</sourceDirectory>
- <scriptSourceDirectory>${basedir}/src/main/scripts</scriptSourceDirectory>
- <testSourceDirectory>${basedir}/src/test/java</testSourceDirectory>
- <outputDirectory>${basedir}/target/classes</outputDirectory>
- <testOutputDirectory>${basedir}/target/test-classes</testOutputDirectory>
+ <sourceDirectory>/home/jenkins/82467a7c/workspace/aven_maven-box_maven-site_master/src/main/java</sourceDirectory>
+ <scriptSourceDirectory>/home/jenkins/82467a7c/workspace/aven_maven-box_maven-site_master/src/main/scripts</scriptSourceDirectory>
+ <testSourceDirectory>/home/jenkins/82467a7c/workspace/aven_maven-box_maven-site_master/src/test/java</testSourceDirectory>
+ <outputDirectory>/home/jenkins/82467a7c/workspace/aven_maven-box_maven-site_master/target/classes</outputDirectory>
+ <testOutputDirectory>/home/jenkins/82467a7c/workspace/aven_maven-box_maven-site_master/target/test-classes</testOutputDirectory>
...
</build>
</project></pre></div>
-<p>If the values of a <code>*Directory</code> element above is set as an absolute path (when their properties are expanded) then that directory is used. Otherwise, it is relative to the base build directory: <code>${basedir}</code>. <b>Please note that the</b> <code>scriptSourceDirectory</code> <b>is nowhere used in Maven and is obsolete</b>.</p></section><section>
+<p>If the values of a <code>*Directory</code> element above is set as an absolute path (when their properties are expanded) then that directory is used. Otherwise, it is relative to the base build directory: <code>${project.basedir}</code>. <b>Please note that the</b> <code>scriptSourceDirectory</code> <b>is nowhere used in Maven and is obsolete</b>.</p></section><section>
<h4><a id="Extensions">Extensions</a></h4>
<p>Extensions are a list of artifacts that are to be used in this build. They will be included in the running build's classpath. They can enable extensions to the build process (such as add an ftp provider for the Wagon transport mechanism), as well as make plugins active which make changes to the build lifecycle. In short, extensions are artifacts that are activated during build. The extensions do not have to actually do anything nor contain a Mojo. For this reason, extensions are excellent for specifying one out of multiple implementations of a common plugin interface.</p>
<div class="verbatim source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -968,7 +968,7 @@ Display parameters as parsed by Maven (i
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
<reporting>
- <outputDirectory>${basedir}/target/site</outputDirectory>
+ <outputDirectory>/home/jenkins/82467a7c/workspace/aven_maven-box_maven-site_master/target/site</outputDirectory>
<plugins>
<plugin>
<artifactId>maven-project-info-reports-plugin</artifactId>
@@ -981,7 +981,7 @@ Display parameters as parsed by Maven (i
</reporting>
...
</project></pre></div>
-<p>The other difference is the <code>outputDirectory</code> element under <code>plugin</code>. In the case of reporting, the output directory is <code>${basedir}/target/site</code> by default.</p><section>
+<p>The other difference is the <code>outputDirectory</code> element under <code>plugin</code>. In the case of reporting, the output directory is <code>${project.basedir}/target/site</code> by default.</p><section>
<h3><a id="Report_Sets">Report Sets</a></h3>
<p>It is important to keep in mind that an individual plugin may have multiple goals. Each goal may have a separate configuration. Report sets configure execution of a report plugin's goals. Does this sound familiar - deja-vu? The same thing was said about build's <code>execution</code> element with one difference: you cannot bind a report to another phase. Sorry.</p>
<p>For example, suppose you wanted to configure the <code>javadoc:javadoc</code> goal to link to "<a class="externalLink" href="http://java.sun.com/j2se/1.5.0/docs/api/">http://java.sun.com/j2se/1.5.0/docs/api/</a>", but only the <code>javadoc</code> goal (not the goal <code>maven-javadoc-plugin:jar</code>). We would also like this configuration passed to its children, and set <code>inherited</code> to true. The <code>reportSet</code> would resemble the following:</p>