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 sl...@apache.org on 2023/02/09 00:34:07 UTC
svn commit: r1907531 [20/25] - in /maven/website/content: ./ apache-resource-bundles/ archives/maven-2.x/ background/ developers/ developers/conventions/ developers/release/ developers/website/ docs/ docs/2.0.1/ docs/2.0.10/ docs/2.0.11/ docs/2.0.2/ do...
Modified: maven/website/content/plugin-developers/common-bugs.html
==============================================================================
--- maven/website/content/plugin-developers/common-bugs.html (original)
+++ maven/website/content/plugin-developers/common-bugs.html Thu Feb 9 00:34:05 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/apt/plugin-developers/common-bugs.apt at 2023-02-08
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/markdown/plugin-developers/common-bugs.md at 2023-02-09
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
@@ -48,8 +48,8 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/" class="externalLink" title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../index.html" title="Maven">Maven</a><span class="divider">/</span></li>
- <li class="active ">Common Bugs and Pitfalls <a href="https://github.com/apache/maven-site/tree/master/content/apt/plugin-developers/common-bugs.apt"><img src="../images/accessories-text-editor.png" title="Edit" /></a></li>
- <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-08</li>
+ <li class="active ">Common Bugs and Pitfalls <a href="https://github.com/apache/maven-site/tree/master/content/markdown/plugin-developers/common-bugs.md"><img src="../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-09</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../scm.html" title="Get Sources">Get Sources</a></li>
<li class="pull-right"><a href="../download.cgi" title="Download">Download</a></li>
@@ -136,43 +136,81 @@
</div>
</header>
<main id="bodyColumn" class="span10" >
-<section>
-<h1>Common Bugs and Pitfalls</h1>
+<!--
+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.
+-->
+<section><section>
+<h2>Common Bugs and Pitfalls</h2>
<p>Maven is not the smallest project in terms of source code and has as such already suffered from many bugs. Having a closer look at all the issues revealed some coding problems that had widespread among the various subcomponents. This document lists these commonly occurring anti patterns in order to help the Maven community to prevent rather than fix bugs. Note that the primary focus is on pointing out problems that are subtle in their nature rather than giving a comprehensive guide for Java or Maven development.</p>
<ul>
-<li><a href="#Reading_and_Writing_Text_Files">Reading and Writing Text Files</a></li>
-<li><a href="#Converting_between_URLs_and_Filesystem_Paths">Converting between URLs and Filesystem Paths</a></li>
-<li><a href="#Handling_Strings_Case-insensitively">Handling Strings Case-insensitively</a></li>
-<li><a href="#Creating_Resource_Bundle_Families">Creating Resource Bundle Families</a></li>
-<li><a href="#Using_System_Properties">Using System Properties</a></li>
-<li><a href="#Using_Shutdown_Hooks">Using Shutdown Hooks</a></li>
-<li><a href="#Resolving_Relative_Paths">Resolving Relative Paths</a></li>
-<li><a href="#Determining_the_Output_Directory_for_a_Site_Report">Determining the Output Directory for a Site Report</a></li>
-<li><a href="#Retrieving_the_Mojo_Logger">Retrieving the Mojo Logger</a></li></ul><section>
-<h2><a id="Reading_and_Writing_Text_Files">Reading and Writing Text Files</a></h2>
+
+<li>
+<p><a href="Reading_and_Writing_Text_Files">Reading and Writing Text Files</a></p></li>
+<li>
+<p><a href="Converting_between_URLs_and_Filesystem_Paths">Converting between URLs and Filesystem Paths</a></p></li>
+<li>
+<p><a href="Handling_Strings_Case-insensitively">Handling Strings Case-insensitively</a></p></li>
+<li>
+<p><a href="Creating_Resource_Bundle_Families">Creating Resource Bundle Families</a></p></li>
+<li>
+<p><a href="Using_System_Properties">Using System Properties</a></p></li>
+<li>
+<p><a href="Using_Shutdown_Hooks">Using Shutdown Hooks</a></p></li>
+<li>
+<p><a href="Resolving_Relative_Paths">Resolving Relative Paths</a></p></li>
+<li>
+<p><a href="Determining_the_Output_Directory_for_a_Site_Report">Determining the Output Directory for a Site Report</a></p></li>
+<li>
+<p><a href="Retrieving_the_Mojo_Logger">Retrieving the Mojo Logger</a></p></li>
+</ul><section>
+<h3>Reading and Writing Text Files</h3>
<p>Textual content is composed of characters while file systems merely store byte streams. A file encoding (aka charset) is used to convert between bytes and characters. The challenge is using the right file encoding.</p>
<p>The JVM has this notion of a default encoding (given by the <code>file.encoding</code> property) which it derives from a system's locale. While this might be a convenient feature sometimes, using this default encoding for a project build is in general a bad idea: The build output will depend on the machine/developer who runs the build. As such, usage of the default encoding threatens the dream of a reproducible build.</p>
<p>For example, if developer A has UTF-8 as default encoding while developer B uses ISO-8859-1, text files are very likely to get messed up during resource filtering or similar tasks.</p>
<p>Therefore, developers should avoid any direct or indirect usage of the classes/methods that simply employ the platform's default encoding. For instance, <code>FileWriter</code> and <code>FileReader</code> should usually be avoided:</p>
-<div class="source"><pre class="prettyprint linenums">/*
+
+<div class="source"><pre class="prettyprint linenums"><code>/*
* FIXME: This assumes the source file is using the platform's default encoding.
*/
-Reader reader = new FileReader( javaFile );</pre></div>
+Reader reader = new FileReader( javaFile );
+</code></pre></div>
<p>Instead, the classes <code>OutputStreamWriter</code> and <code>OutputStreamReader</code> can be used in combination with an explicit encoding value. This encoding value can be retrieved from a mojo parameter such that the user can configure the plugin to fit his/her needs.</p>
<p>To save the user from configuring each plugin individually, conventions have been established that allow a user to centrally configure the file encoding per POM. Plugin developers should respect these conventions whereever possible:</p>
<ul>
-<li><a class="externalLink" href="https://cwiki.apache.org/confluence/display/MAVEN/POM+Element+for+Source+File+Encoding">Source File Encoding</a></li>
-<li><a class="externalLink" href="http://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration">Report Output Encoding</a></li></ul>
+
+<li>
+<p><a href="https://cwiki.apache.org/confluence/display/MAVEN/POM+Element+for+Source+File+Encoding" class="externalLink">Source File Encoding</a></p></li>
+<li>
+<p><a href="http://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration" class="externalLink">Report Output Encoding</a></p></li>
+</ul>
<p>Finally note that XML files require special handling because they are equipped with an encoding declaration in the XML prolog. Reading or writing XML files with an encoding that does not match their XML prolog's <code>encoding</code> attribute is a bad idea:</p>
-<div class="source"><pre class="prettyprint linenums">/*
+
+<div class="source"><pre class="prettyprint linenums"><code>/*
* FIXME: This assumes the XML encoding declaration matches the platform's default encoding.
*/
Writer writer = new FileWriter( xmlFile );
-writer.write( xmlContent );</pre></div>
-<p>To ease the correct processing of XML files, developers are encouraged to use <code><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-utils/apidocs/org/codehaus/plexus/util/ReaderFactory.html#newXmlReader(java.io.File)">ReaderFactory.newXmlReader()</a></code> and <code><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-utils/apidocs/org/codehaus/plexus/util/WriterFactory.html#newXmlWriter(java.io.File)">WriterFactory.newXmlWriter()</a></code> from the Plexus Utilities.</p></section><section>
-<h2><a id="Converting_between_URLs_and_Filesystem_Paths">Converting between URLs and Filesystem Paths</a></h2>
+writer.write( xmlContent );
+</code></pre></div>
+<p>To ease the correct processing of XML files, developers are encouraged to use <code>[ReaderFactory.newXmlReader()](https://codehaus-plexus.github.io/plexus-utils/apidocs/org/codehaus/plexus/util/ReaderFactory.html#newXmlReader(java.io.File))</code> and <code>[WriterFactory.newXmlWriter()](https://codehaus-plexus.github.io/plexus-utils/apidocs/org/codehaus/plexus/util/WriterFactory.html#newXmlWriter(java.io.File))</code> from the Plexus Utilities.</p></section><section>
+<h3>Converting between URLs and Filesystem Paths</h3>
<p>URLs and filesystem paths are really two different things and converting between them is not trivial. The main source of problems is that different encoding rules apply for the strings that make up a URL or filesystem path. For example, consider the following code snippet and its associated console output:</p>
-<div class="source"><pre class="prettyprint linenums">File file = new File( "foo bar+foo" );
+
+<div class="source"><pre class="prettyprint linenums"><code>File file = new File( "foo bar+foo" );
URL url = file.toURI().toURL();
System.out.println( file.toURL() );
@@ -185,51 +223,60 @@ System.out.println( url.getPath() );
> /C:/temp/foo%20bar+foo
System.out.println( URLDecoder.decode( url.getPath(), "UTF-8" ) );
-> /C:/temp/foo bar foo</pre></div>
-<p>First of all, please note that <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/io/File.html#toURL()">File.toURL()</a></code> does not escape the space character (and others). This yields an invalid URL, as per <a class="externalLink" href="http://www.faqs.org/rfcs/rfc2396.html">RFC 2396, section 2.4.3 "Excluded US-ASCII Characters"</a>. The class <code>java.net.URL</code> will silently accept such invalid URLs, in contrast <code>java.net.URI</code> will not (see also <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/net/URL.html#toURI()">URL.toURI()</a></code>). For this reason, <code>File.toURL()</code> has been deprecated and should be replaced with <code>File.toURI().toURL()</code>.</p>
-<p>Next, <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/net/URL.html#getPath()">URL.getPath()</a></code> does in general not return a string that can be used as a filesystem path. It returns a substring of the URL and as such can contain escape sequences. The prominent example is the space character which will show up as "%20". People sometimes hack around this by means of <code>replace("%20", " ")</code> but that does simply not cover all cases. It's worth to mention that on the other hand the related method <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/net/URI.html#getPath()">URI.getPath()</a></code> does decode escapes but still the result is not a filesystem path (compare the source for the constructor <code>File(URI)</code>). To summarize, the following idiom is to be avoided:</p>
-<div class="source"><pre class="prettyprint linenums">URL url = new URL( "file:/C:/Program%20Files/Java/bin/java.exe" );
+> /C:/temp/foo bar foo
+</code></pre></div>
+<p>First of all, please note that <code>[File.toURL()](http://java.sun.com/javase/6/docs/api/java/io/File.html#toURL())</code> does not escape the space character (and others). This yields an invalid URL, as per <a href="http://www.faqs.org/rfcs/rfc2396.html" class="externalLink">RFC 2396, section 2.4.3 “Excluded US-ASCII Characters”</a>. The class <code>java.net.URL</code> will silently accept such invalid URLs, in contrast <code>java.net.URI</code> will not (see also <code>[URL.toURI()](http://java.sun.com/javase/6/docs/api/java/net/URL.html#toURI())</code>). For this reason, <code>File.toURL()</code> has been deprecated and should be replaced with <code>File.toURI().toURL()</code>.</p>
+<p>Next, <code>[URL.getPath()](http://java.sun.com/javase/6/docs/api/java/net/URL.html#getPath())</code> does in general not return a string that can be used as a filesystem path. It returns a substring of the URL and as such can contain escape sequences. The prominent example is the space character which will show up as “%20”. People sometimes hack around this by means of <code>replace("%20", " ")</code> but that does simply not cover all cases. It's worth to mention that on the other hand the related method <code>[URI.getPath()](http://java.sun.com/javase/6/docs/api/java/net/URI.html#getPath())</code> does decode escapes but still the result is not a filesystem path (compare the source for the constructor <code>File(URI)</code>). To summarize, the following idiom is to be avoided:</p>
+
+<div class="source"><pre class="prettyprint linenums"><code>URL url = new URL( "file:/C:/Program%20Files/Java/bin/java.exe" );
/*
* FIXME: This does not decode percent encoded characters.
*/
-File path = new File( url.getPath() );</pre></div>
-<p>To decode a URL, people sometimes also choose <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/net/URLDecoder.html">java.net.URLDecoder</a></code>. The pitfall with this class is that is actually performs HTML form decoding which is yet another encoding and not the same as the URL encoding (compare the last paragraph in class javadoc about <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/net/URL.html">java.net.URL</a></code>). For instance, a <code>URLDecoder</code> will erroneously convert the character "+" into a space as illustrated by the last sysout in the example above.</p>
-<p>In an ideal world, code targetting JRE 1.4+ could easily avoid these problems by using the constructor <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/io/File.html#File(java.net.URI)">File(URI)</a></code> as suggested by the following snippet:</p>
-<div class="source"><pre class="prettyprint linenums">URL url = new URL( "file:/C:/Documents and Settings/user/.m2/settings.xml" );
+File path = new File( url.getPath() );
+</code></pre></div>
+<p>To decode a URL, people sometimes also choose <code>[java.net.URLDecoder](http://java.sun.com/javase/6/docs/api/java/net/URLDecoder.html)</code>. The pitfall with this class is that is actually performs HTML form decoding which is yet another encoding and not the same as the URL encoding (compare the last paragraph in class javadoc about <code>[java.net.URL](http://java.sun.com/javase/6/docs/api/java/net/URL.html)</code>). For instance, a <code>URLDecoder</code> will erroneously convert the character “+” into a space as illustrated by the last sysout in the example above.</p>
+<p>In an ideal world, code targetting JRE 1.4+ could easily avoid these problems by using the constructor <code>[File(URI)](http://java.sun.com/javase/6/docs/api/java/io/File.html#File(java.net.URI))</code> as suggested by the following snippet:</p>
+
+<div class="source"><pre class="prettyprint linenums"><code>URL url = new URL( "file:/C:/Documents and Settings/user/.m2/settings.xml" );
/*
* FIXME: This assumes the URL is fully compliant with RFC 3986.
*/
-File path = new File( new URI( url.toExternalForm() ) );</pre></div>
-<p>The remaining source of frustration is the conversion from <code>URL</code> to <code>URI</code>. As already said, the <code>URL</code> class accepts malformed URLs which will make the constructor of <code>URI</code> throw an exception. And indeed, class loaders from Sun JREs up to Java 1.4 will deliver malformed URLs when queried for a resource. Likewise, the class loaders employed by Maven 2.x deliver malformed resource URLs regardless of the JRE version (see <a class="externalLink" href="https://issues.apache.org/jira/browse/MNG-3607">MNG-3607</a>).</p>
-<p>For all these reasons, it is recommended to use <code><a class="externalLink" href="http://commons.apache.org/io/api-release/org/apache/commons/io/FileUtils.html#toFile(java.net.URL)">FileUtils.toFile()</a></code> from Commons IO or <code><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-utils/apidocs/org/codehaus/plexus/util/FileUtils.html#toFile(java.net.URL)">FileUtils.toFile()</a></code> from a recent Plexus Utilities.</p></section><section>
-<h2><a id="Handling_Strings_Case-insensitively">Handling Strings Case-insensitively</a></h2>
-<p>When developers need to compare strings without regard to case or want to realize a map with case-insensitive string keys, they often employ <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/lang/String.html#toLowerCase()">String.toLowerCase()</a></code> or <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/lang/String.html#toUpperCase()">String.toUpperCase()</a></code> to create a "normalized" string before doing a simple <code>String.equals()</code>. Now, the <code>to*Case()</code> methods are overloaded: One takes no arguments and one takes a <code>Locale</code> object.</p>
-<p>The gotcha with the arg-less methods is that their output depends on the default locale of the JVM but the default locale is out of control of the developer. That means the string expected by the developer (who runs/tests his code in a JVM using locale <code>xy</code>) does not necessarily match the string seen by another user (that runs a JVM with locale <code>ab</code>). For example, the comparison shown in the next code snippet is likely to fail for systems with default locale Turkish because Turkish has unusual casing rules for the characters "i" and "I":</p>
-<div class="source"><pre class="prettyprint linenums">/*
+File path = new File( new URI( url.toExternalForm() ) );
+</code></pre></div>
+<p>The remaining source of frustration is the conversion from <code>URL</code> to <code>URI</code>. As already said, the <code>URL</code> class accepts malformed URLs which will make the constructor of <code>URI</code> throw an exception. And indeed, class loaders from Sun JREs up to Java 1.4 will deliver malformed URLs when queried for a resource. Likewise, the class loaders employed by Maven 2.x deliver malformed resource URLs regardless of the JRE version (see <a href="https://issues.apache.org/jira/browse/MNG-3607" class="externalLink">MNG-3607</a>).</p>
+<p>For all these reasons, it is recommended to use <code>[FileUtils.toFile()](http://commons.apache.org/io/api-release/org/apache/commons/io/FileUtils.html#toFile(java.net.URL))</code> from Commons IO or <code>[FileUtils.toFile()](https://codehaus-plexus.github.io/plexus-utils/apidocs/org/codehaus/plexus/util/FileUtils.html#toFile(java.net.URL))</code> from a recent Plexus Utilities.</p></section><section>
+<h3>Handling Strings Case-insensitively</h3>
+<p>When developers need to compare strings without regard to case or want to realize a map with case-insensitive string keys, they often employ <code>[String.toLowerCase()](http://java.sun.com/javase/6/docs/api/java/lang/String.html#toLowerCase())</code> or <code>[String.toUpperCase()](http://java.sun.com/javase/6/docs/api/java/lang/String.html#toUpperCase())</code> to create a “normalized” string before doing a simple <code>String.equals()</code>. Now, the <code>to\*Case()</code> methods are overloaded: One takes no arguments and one takes a <code>Locale</code> object.</p>
+<p>The gotcha with the arg-less methods is that their output depends on the default locale of the JVM but the default locale is out of control of the developer. That means the string expected by the developer (who runs/tests his code in a JVM using locale <code>xy</code>) does not necessarily match the string seen by another user (that runs a JVM with locale <code>ab</code>). For example, the comparison shown in the next code snippet is likely to fail for systems with default locale Turkish because Turkish has unusual casing rules for the characters “i” and “I”:</p>
+
+<div class="source"><pre class="prettyprint linenums"><code>/*
* FIXME: This assumes the casing rules of the current platform
* match the rules for the English locale.
*/
if ( "info".equals( debugLevel.toLowerCase() ) )
- logger.info( message );</pre></div>
-<p>For case-insensitive string comparisons which should be locale-insensitive, the method <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/lang/String.html#equalsIgnoreCase(java.lang.String)">String.equalsIgnoreCase()</a></code> should be used instead. If only a substring like a prefix/suffix should be compared, the method <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/lang/String.html#regionMatches(boolean,%20int,%20java.lang.String,%20int,%20int)">String.regionMatches()</a></code> can be used instead.</p>
-<p>If the usage of <code>String.to*Case()</code> cannot be avoided, the overloaded version taking a <code>Locale</code> object should be used, passing in <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/util/Locale.html#ENGLISH">Locale.ENGLISH</a></code>. The resulting code will still run on Non-English systems, the parameter only locks down the casing rules used for the string comparison such that the code delivers the same results on all platforms.</p></section><section>
-<h2><a id="Creating_Resource_Bundle_Families">Creating Resource Bundle Families</a></h2>
-<p>Especially reporting plugins employ resource bundles to support internationalization. One language (usually English) is provided as the fallback/default language in the base resource bundle. Due to the lookup strategy performed by <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html#getBundle(java.lang.String,%20java.util.Locale,%20java.lang.ClassLoader)">ResourceBundle.getBundle()</a></code>, one must always provide a dedicated resource bundle for this default language, too. This bundle should be empty because it inherits the strings via the parent chain from the base bundle, but it must exist.</p>
+ logger.info( message );
+</code></pre></div>
+<p>For case-insensitive string comparisons which should be locale-insensitive, the method <code>[String.equalsIgnoreCase()](http://java.sun.com/javase/6/docs/api/java/lang/String.html#equalsIgnoreCase(java.lang.String))</code> should be used instead. If only a substring like a prefix/suffix should be compared, the method <code>[String.regionMatches()](http://java.sun.com/javase/6/docs/api/java/lang/String.html#regionMatches(boolean,%20int,%20java.lang.String,%20int,%20int))</code> can be used instead.</p>
+<p>If the usage of <code>String.to\*Case()</code> cannot be avoided, the overloaded version taking a <code>Locale</code> object should be used, passing in <code>[Locale.ENGLISH](http://java.sun.com/javase/6/docs/api/java/util/Locale.html#ENGLISH)</code>. The resulting code will still run on Non-English systems, the parameter only locks down the casing rules used for the string comparison such that the code delivers the same results on all platforms.</p></section><section>
+<h3>Creating Resource Bundle Families</h3>
+<p>Especially reporting plugins employ resource bundles to support internationalization. One language (usually English) is provided as the fallback/default language in the base resource bundle. Due to the lookup strategy performed by <code>[ResourceBundle.getBundle()](http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html#getBundle(java.lang.String,%20java.util.Locale,%20java.lang.ClassLoader))</code>, one must always provide a dedicated resource bundle for this default language, too. This bundle should be empty because it inherits the strings via the parent chain from the base bundle, but it must exist.</p>
<p>The following example illustrates this requirement. Imagine the broken resource bundle family shown below which is intended to provide localization for English, German and French:</p>
-<div>
-<pre>src/
+
+<div class="source"><pre class="prettyprint linenums"><code>src/
+- main/
+- resources/
+- mymojo-report.properties
+- mymojo-report_de.properties
- +- mymojo-report_fr.properties</pre></div>
+ +- mymojo-report_fr.properties
+</code></pre></div>
<p>Now, if a resource bundle is to be looked up for English on a JVM whose default locale happens to be French, the bundle <code>mymojo-report_fr.properties</code> will be loaded instead of the intended bundle <code>mymojo-report.properties</code>.</p>
-<p>Reporting plugins that suffer from this bug can easily be detected by executing <code>mvn site -D locales=xy,en</code> where <code>xy</code> denotes any other language code supported by the particular plugin. Specifying <code>xy</code> as the first locale will have the Maven Site Plugin change the JVM's default locale to <code>xy</code> which in turn causes the lookup for <code>en</code> to fail as outlined above unless the plugin has a dedicated resource bundle for English.</p></section><section>
-<h2><a id="Using_System_Properties">Using System Properties</a></h2>
-<p>Maven's command line supports the definition of system properties via arguments of the form <code>-D key=value</code>. While these properties are called system properties, plugins should never use <code><a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String)">System.getProperty()</a></code> and related methods to query these properties. For example, the following code snippet will not work reliably when Maven is embedded, say into an IDE or a CI server:</p>
-<div class="source"><pre class="prettyprint linenums">public MyMojo extends AbstractMojo
+<p>Reporting plugins that suffer from this bug can easily be detected by executing <code>mvn site -D locales\=xy,en</code> where <code>xy</code> denotes any other language code supported by the particular plugin. Specifying <code>xy</code> as the first locale will have the Maven Site Plugin change the JVM's default locale to <code>xy</code> which in turn causes the lookup for <code>en</code> to fail as outlined above unless the plugin has a dedicated resource bundle for English.</p></section><section>
+<h3>Using System Properties</h3>
+<p>Maven's command line supports the definition of system properties via arguments of the form <code>-D key\=value</code>. While these properties are called system properties, plugins should never use <code>[System.getProperty()](http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String))</code> and related methods to query these properties. For example, the following code snippet will not work reliably when Maven is embedded, say into an IDE or a CI server:</p>
+
+<div class="source"><pre class="prettyprint linenums"><code>public MyMojo extends AbstractMojo
{
public void execute()
{
@@ -238,11 +285,13 @@ if ( "info".equals( debugLevel
*/
String value = System.getProperty( "maven.test.skip" );
}
-}</pre></div>
-<p>The problem is that the properties managed by the <code>System</code> class are global, i.e. shared among all threads in the current JVM. To prevent conflicts with other code running in the same JVM, Maven plugins should instead query the execution properties. These can be obtained from <code><a class="externalLink" href="https://maven.apache.org/ref/current/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getExecutionProperties()">MavenSession.getExecutionProperties()</a></code>.</p></section><section>
-<h2><a id="Using_Shutdown_Hooks">Using Shutdown Hooks</a></h2>
+}
+</code></pre></div>
+<p>The problem is that the properties managed by the <code>System</code> class are global, i.e. shared among all threads in the current JVM. To prevent conflicts with other code running in the same JVM, Maven plugins should instead query the execution properties. These can be obtained from <code>[MavenSession.getExecutionProperties()](https://maven.apache.org/ref/current/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getExecutionProperties())</code>.</p></section><section>
+<h3>Using Shutdown Hooks</h3>
<p>People occasionally employ shutdown hooks to perform cleanup tasks, e.g. to delete temporary files as shown in the example below:</p>
-<div class="source"><pre class="prettyprint linenums">public MyMojo extends AbstractMojo
+
+<div class="source"><pre class="prettyprint linenums"><code>public MyMojo extends AbstractMojo
{
public void execute()
{
@@ -253,22 +302,23 @@ if ( "info".equals( debugLevel
*/
tempFile.deleteOnExit();
}
-}</pre></div>
+}
+</code></pre></div>
<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>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>
+<h3>Resolving Relative Paths</h3>
+<p>It is common practice for users of Maven to specify relative paths in the POM, not to mention that the Super POM does so, too. The intention is to resolve such relative paths against the base directory of the current project. In other words, the paths <code>target/classes</code> and <code>$\{basedir\}/target/classes</code> should resolve to the same directory for a given POM.</p>
+<p>Unfortunately, the class <code>[java.io.File](http://java.sun.com/javase/6/docs/api/java/io/File.html)</code> does not resolve relative paths against the project's base directory. As mentioned in its class javadoc, it resolves relative paths against the current working directory. In plain English: Unless a Maven component has complete control over the current working directory, any usage of <code>java.io.File</code> in combination with a relative path is a bug.</p>
<p>At first glance, one might be tempted to argue that the project base directory is equal to the current working directory. However, this assumption is generally not true. Consider the following scenarios:</p>
-<ol style="list-style-type: lower-alpha">
-<li>Reactor Builds
-<p>When a child module is build during a reactor build, the current working directory is usually the base directory of the parent project, not the base directory of the current module. That is the most common scenario where users are faced with the bug.</p></li>
-<li>Embedded Maven Invocations
-<p>Other tools, most notably IDEs, that run Maven under the hood may have set the current working directory to their installation folder or whatever they like.</p></li>
-<li>Maven Invocations using the <code>-f</code> Switch
-<p>While it is surely an uncommon use-case, the user is free to invoke Maven from an arbitrary working directory by specifying an absolute path like <code>mvn -f /home/me/projects/demo/pom.xml</code>.</p></li></ol>
+<p>a Reactor Builds</p>
+<p>When a child module is build during a reactor build, the current working directory is usually the base directory of the parent project, not the base directory of the current module. That is the most common scenario where users are faced with the bug.</p>
+<p>a Embedded Maven Invocations</p>
+<p>Other tools, most notably IDEs, that run Maven under the hood may have set the current working directory to their installation folder or whatever they like.</p>
+<p>a Maven Invocations using the <code>-f</code> Switch</p>
+<p>While it is surely an uncommon use-case, the user is free to invoke Maven from an arbitrary working directory by specifying an absolute path like <code>mvn -f /home/me/projects/demo/pom.xml</code>.</p>
<p>Hence this example code is prone to misbehave:</p>
-<div class="source"><pre class="prettyprint linenums">public MyMojo extends AbstractMojo
+
+<div class="source"><pre class="prettyprint linenums"><code>public MyMojo extends AbstractMojo
{
/**
* @parameter
@@ -283,18 +333,22 @@ if ( "info".equals( debugLevel
*/
File outputDir = new File( outputDirectory ).getAbsoluteFile();
}
-}</pre></div>
+}
+</code></pre></div>
<p>In order to guarantee reliable builds, Maven and its plugins must manually resolve relative paths against the project's base directory. A simple idiom like the following will do just fine:</p>
-<div class="source"><pre class="prettyprint linenums">File file = new File( path );
+
+<div class="source"><pre class="prettyprint linenums"><code>File file = new File( path );
if ( !file.isAbsolute() )
{
file = new File( project.getBasedir(), file );
-}</pre></div>
-<p>Many Maven plugins can get this resolution automatically if they declare their affected mojo parameters of type <code>java.io.File</code> instead of <code>java.lang.String</code>. This subtle difference in parameter types will trigger a feature known as <i>path translation</i>, i.e. the Maven core will automatically resolve relative paths when it pumps the XML configuration into a mojo.</p></section><section>
-<h2><a id="Determining_the_Output_Directory_for_a_Site_Report">Determining the Output Directory for a Site Report</a></h2>
+}
+</code></pre></div>
+<p>Many Maven plugins can get this resolution automatically if they declare their affected mojo parameters of type <code>java.io.File</code> instead of <code>java.lang.String</code>. This subtle difference in parameter types will trigger a feature known as <em>path translation</em>, i.e. the Maven core will automatically resolve relative paths when it pumps the XML configuration into a mojo.</p></section><section>
+<h3>Determining the Output Directory for a Site Report</h3>
<p>Most reporting plugins inherit from <code>AbstractMavenReport</code>. In doing so, they need to implement the inherited but abstract method <code>getOutputDirectory()</code>. To implement this method, plugins usually declare a field named <code>outputDirectory</code> which they return in the method. Nothing wrong so far.</p>
-<p>Now, some plugins need to create additional files in the report output directory that accompany the report generated via the sink interface. While it is tempting to use either the method <code>getOutputDirectory()</code> or the field <code>outputDirectory</code> directly in order to setup a path for the output files, this leads most likely to a bug. More precisely, those plugins will not properly output files when run by the Maven Site Plugin as part of the site lifecycle. This is best noticed when the output directory for the site is configured directly in the Maven Site Plugin such that it deviates from the expression <code>${project.reporting.outputDirectory}</code> that the plugins use by default. Multi-language site generation is another scenario to exploit this bug which is illustrated below:</p>
-<div class="source"><pre class="prettyprint linenums">public MyReportMojo extends AbstractMavenReport
+<p>Now, some plugins need to create additional files in the report output directory that accompany the report generated via the sink interface. While it is tempting to use either the method <code>getOutputDirectory()</code> or the field <code>outputDirectory</code> directly in order to setup a path for the output files, this leads most likely to a bug. More precisely, those plugins will not properly output files when run by the Maven Site Plugin as part of the site lifecycle. This is best noticed when the output directory for the site is configured directly in the Maven Site Plugin such that it deviates from the expression <code>$\{project.reporting.outputDirectory\}</code> that the plugins use by default. Multi-language site generation is another scenario to exploit this bug which is illustrated below:</p>
+
+<div class="source"><pre class="prettyprint linenums"><code>public MyReportMojo extends AbstractMavenReport
{
/**
* @parameter default-value="${project.reporting.outputDirectory}"
@@ -314,13 +368,15 @@ if ( !file.isAbsolute() )
*/
outputDirectory.mkdirs();
}
-}</pre></div>
+}
+</code></pre></div>
<p>There are in principal two situations in which a report mojo could be invoked. The mojo might be run directly from the command line or the default build lifecycle or it might be run indirectly as part of the site generation along with other report mojos. The glaring difference between these two invocations is the way the output directory is controlled. In the first case, the parameter <code>outputDirectory</code> from the mojo itself is used. In the second case however, the Maven Site Plugin takes over control and will set the output directory according to its own configuration by calling <code>MavenReport.setReportOutputDirectory()</code> on the reports being generated.</p>
<p>Therefore, developers should always use <code>MavenReport.getReportOutputDirectory()</code> if they need to query the effective output directory for the report. The implementation of <code>AbstractMavenReport.getOutputDirectory()</code> is only intended as a fallback in case the mojo is not run as part of the site generation.</p></section><section>
-<h2><a id="Retrieving_the_Mojo_Logger">Retrieving the Mojo Logger</a></h2>
-<p>Maven employs an IoC container named Plexus to setup a plugin's mojos before their execution. In other words, components required by a mojo will be provided by means of dependency injection, more precisely field injection. The important point to keep in mind is that this field injection happens <i>after</i> the mojo's constructor has finished. This means that references to injected components are invalid during the construction time of the mojo.</p>
+<h3>Retrieving the Mojo Logger</h3>
+<p>Maven employs an IoC container named Plexus to setup a plugin's mojos before their execution. In other words, components required by a mojo will be provided by means of dependency injection, more precisely field injection. The important point to keep in mind is that this field injection happens <em>after</em> the mojo's constructor has finished. This means that references to injected components are invalid during the construction time of the mojo.</p>
<p>For example, the next snippet tries to retrieve the mojo logger during construction time but the mojo logger is an injected component and as such has not been properly initialized yet:</p>
-<div class="source"><pre class="prettyprint linenums">public MyMojo extends AbstractMojo
+
+<div class="source"><pre class="prettyprint linenums"><code>public MyMojo extends AbstractMojo
{
/*
* FIXME: This will retrieve a wrong logger instead of the intended mojo logger.
@@ -331,8 +387,9 @@ if ( !file.isAbsolute() )
{
log.debug( "..." );
}
-}</pre></div>
-<p>In case of the logger, the above mojo will simply use a default console logger, i.e. the code defect is not immediately noticeable by a <code>NullPointerException</code>. This default logger will however use a different message format for its output and also outputs debug messages even if Maven's debug mode was not enabled. For this reason, developers must not try to cache the logger during construction time. The method <code>getLog()</code> is fast enough and can simply be called whenever one needs it. +---</p></section></section>
+}
+</code></pre></div>
+<p>In case of the logger, the above mojo will simply use a default console logger, i.e. the code defect is not immediately noticeable by a <code>NullPointerException</code>. This default logger will however use a different message format for its output and also outputs debug messages even if Maven's debug mode was not enabled. For this reason, developers must not try to cache the logger during construction time. The method <code>getLog()</code> is fast enough and can simply be called whenever one needs it. +—</p></section></section></section>
</main>
</div>
</div>
Modified: maven/website/content/plugin-developers/cookbook/index.html
==============================================================================
--- maven/website/content/plugin-developers/cookbook/index.html (original)
+++ maven/website/content/plugin-developers/cookbook/index.html Thu Feb 9 00:34:05 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/apt/plugin-developers/cookbook/index.apt at 2023-02-08
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/markdown/plugin-developers/cookbook/index.md at 2023-02-09
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
@@ -10,8 +10,7 @@
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M4" />
- <meta name="author" content="Brett Porter
-Vincent Siveton" />
+ <meta name="author" content="Brett Porter, Vincent Siveton" />
<meta name="date" content="2009-08-02" />
<title>Maven – Plugins Cookbook</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.11.1.min.css" />
@@ -49,8 +48,8 @@ Vincent Siveton" />
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/" class="externalLink" title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../../index.html" title="Maven">Maven</a><span class="divider">/</span></li>
- <li class="active ">Plugins Cookbook <a href="https://github.com/apache/maven-site/tree/master/content/apt/plugin-developers/cookbook/index.apt"><img src="../../images/accessories-text-editor.png" title="Edit" /></a></li>
- <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-08</li>
+ <li class="active ">Plugins Cookbook <a href="https://github.com/apache/maven-site/tree/master/content/markdown/plugin-developers/cookbook/index.md"><img src="../../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-09</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../../scm.html" title="Get Sources">Get Sources</a></li>
<li class="pull-right"><a href="../../download.cgi" title="Download">Download</a></li>
@@ -124,12 +123,34 @@ Vincent Siveton" />
</div>
</header>
<main id="bodyColumn" class="span10" >
-<section>
-<h1>Maven Extensions Cookbook</h1>
+<!--
+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.
+-->
+<section><section>
+<h2>Maven Extensions Cookbook</h2>
<p>Extensions are based on components, defined either with Plexus or JSR-330:</p>
<ul>
-<li><a href="./plexus-plugin-upgrade.html">How to upgrade from Plexus javadoc tags to Plexus Java annotations?</a></li>
-<li><a href="/maven-jsr330.html">Using JSR-330 (instead of Plexus Java annotations)</a></li></ul></section>
+
+<li>
+<p><a href="./plexus-plugin-upgrade.html">How to upgrade from Plexus javadoc tags to Plexus Java annotations?</a></p></li>
+<li>
+<p><a href="/maven-jsr330.html">Using JSR-330 (instead of Plexus Java annotations)</a></p></li>
+</ul></section></section>
</main>
</div>
</div>
Modified: maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html
==============================================================================
--- maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html (original)
+++ maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html Thu Feb 9 00:34:05 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/apt/plugin-developers/cookbook/plexus-plugin-upgrade.apt at 2023-02-08
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md at 2023-02-09
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
@@ -48,8 +48,8 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/" class="externalLink" title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../../index.html" title="Maven">Maven</a><span class="divider">/</span></li>
- <li class="active ">Cookbook - How To Upgrade from Plexus Javadoc Tags to Plexus Java Annotations <a href="https://github.com/apache/maven-site/tree/master/content/apt/plugin-developers/cookbook/plexus-plugin-upgrade.apt"><img src="../../images/accessories-text-editor.png" title="Edit" /></a></li>
- <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-08</li>
+ <li class="active ">Cookbook - How To Upgrade from Plexus Javadoc Tags to Plexus Java Annotations <a href="https://github.com/apache/maven-site/tree/master/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md"><img src="../../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-09</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../../scm.html" title="Get Sources">Get Sources</a></li>
<li class="pull-right"><a href="../../download.cgi" title="Download">Download</a></li>
@@ -136,73 +136,105 @@
</div>
</header>
<main id="bodyColumn" class="span10" >
-<section>
-<h1>Cookbook: How To Upgrade from Plexus Javadoc Tags to Plexus Java Annotations?</h1><section>
-<h2>Summary</h2>
+<!--
+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.
+-->
+<section><section>
+<h2>Cookbook: How To Upgrade from Plexus Javadoc Tags to Plexus Java Annotations?</h2><section>
+<h3>Summary</h3>
<p>This recipe describes how to upgrade from Plexus Javadoc Tags to Plexus Java Annotations when defining a Plexus component.</p>
<p>This is done in 2 steps:</p>
-<ol style="list-style-type: decimal">
-<li>replace the <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-maven-plugin/">deprecated <code>plexus-maven-plugin</code></a>, which only supports Plexus Javadoc Tags, with its <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/">successor: <code>plexus-component-metadata</code></a>, which support both Plexus Javadoc Tags and Plexus Java Annotations,</li>
-<li>update sources with <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/">Java Annotations for Plexus</a>.</li></ol>
-<p><b>Notice</b>: if you're targeting components for Maven 3.1.0+, using <a href="/maven-jsr330.html"><code>@Named</code>/<code>@Inject</code> JSR-330 annotations</a> instead of <code>@Component</code>/<code>@Requirement</code> Plexus Java Annotations may be a good next step</p></section><section>
-<h2>Prerequisite Plugins</h2>
+<p>1 replace the <a href="https://codehaus-plexus.github.io/plexus-maven-plugin/" class="externalLink">deprecated <code>plexus-maven-plugin</code></a>, which only supports Plexus Javadoc Tags, with its <a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/" class="externalLink">successor: <code>plexus-component-metadata</code></a>, which support both Plexus Javadoc Tags and Plexus Java Annotations,</p>
+<p>1 update sources with <a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/" class="externalLink">Java Annotations for Plexus</a>.</p>
+<p><strong>Notice</strong>: if you're targeting components for Maven 3.1.0+, using <a href="/maven-jsr330.html"><code>@Named</code>/<code>@Inject</code> JSR-330 annotations</a> instead of <code>@Component</code>/<code>@Requirement</code> Plexus Java Annotations may be a good next step</p></section><section>
+<h3>Prerequisite Plugins</h3>
<p>Here is the list of the plugins used:</p>
-<table class="bodyTable bodyTableBorder">
+<table class="table table-striped">
+<thead>
<tr class="a">
-<th><b>Plugin</b></th>
-<th><b>Version</b></th></tr>
+<th><strong>Plugin</strong></th>
+<th><strong>Version</strong></th></tr></thead><tbody>
<tr class="b">
-<td style="text-align: left;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-maven-plugin/"><code>plexus-maven-plugin</code></a></td>
-<td style="text-align: left;">1.3.8</td></tr>
+<td><a href="https://codehaus-plexus.github.io/plexus-maven-plugin/" class="externalLink"><code>plexus-maven-plugin</code></a></td>
+<td>1.3.8</td></tr>
<tr class="a">
-<td style="text-align: left;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/"><code>plexus-component-metadata</code></a></td>
-<td style="text-align: left;">1.7.1</td></tr></table></section><section>
-<h2>Equivalence Table</h2>
-<table class="bodyTable bodyTableBorder">
+<td><a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/" class="externalLink"><code>plexus-component-metadata</code></a></td>
+<td>1.7.1</td></tr></tbody>
+</table>
+</section><section>
+<h3>Equivalence Table</h3>
+<table class="table table-striped">
+<thead>
<tr class="a">
-<td style="text-align: center;"></td>
-<th><b>plexus-maven-plugin</b></th>
-<th><b>plexus-component-metadata</b></th></tr>
+<th></th>
+<th><strong>plexus-maven-plugin</strong></th>
+<th><strong>plexus-component-metadata</strong></th></tr></thead><tbody>
<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/">project</a> / <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-maven-plugin/plugin-info.html">plugin info</a></td>
-<td style="text-align: center;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/">project</a> / <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/plugin-info.html">plugin info</a></td></tr>
+<td></td>
+<td><a href="https://codehaus-plexus.github.io/plexus-maven-plugin/" class="externalLink">project</a> / <a href="https://codehaus-plexus.github.io/plexus-maven-plugin/plugin-info.html" class="externalLink">plugin info</a></td>
+<td><a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/" class="externalLink">project</a> / <a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/plugin-info.html" class="externalLink">plugin info</a></td></tr>
<tr class="a">
-<th>latest</th>
-<td style="text-align: center;">1.3.8</td>
-<td style="text-align: center;">1.7.1</td></tr>
+<td>latest</td>
+<td>1.3.8</td>
+<td>1.7.1</td></tr>
<tr class="b">
-<th>phase</th>
-<td style="text-align: center;">process-sources</td>
-<td style="text-align: center;">process-classes</td></tr>
+<td>phase</td>
+<td>process-sources</td>
+<td>process-classes</td></tr>
<tr class="a">
-<th>goals</th>
-<td style="text-align: center;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-maven-plugin/descriptor-mojo.html"><code>descriptor</code></a></td>
-<td style="text-align: center;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/generate-metadata-mojo.html"><code>generate-metadata</code></a></td></tr>
+<td>goals</td>
+<td><a href="https://codehaus-plexus.github.io/plexus-maven-plugin/descriptor-mojo.html" class="externalLink"><code>descriptor</code></a></td>
+<td><a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/generate-metadata-mojo.html" class="externalLink"><code>generate-metadata</code></a></td></tr>
<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></td>
+<td><a href="https://codehaus-plexus.github.io/plexus-maven-plugin/merge-descriptors-mojo.html" class="externalLink"><code>merge-descriptors</code></a></td>
+<td>see <code>staticMetadataDirectory</code> parameter  </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>
-<td style="text-align: center;"><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/generate-test-metadata-mojo.html"><code>generate-test-metadata</code></a></td></tr>
+<td>default: <code>${basedir}/src/main/resources/META-INF/plexus</code></td></tr>
<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></td>
+<td><a href="https://codehaus-plexus.github.io/plexus-maven-plugin/test-descriptor-mojo.html" class="externalLink"><code>test-descriptor</code></a></td>
+<td><a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-metadata/generate-test-metadata-mojo.html" class="externalLink"><code>generate-test-metadata</code></a></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>
-<td style="text-align: center;">reporting feature not available</td></tr>
+<td></td>
+<td><a href="https://codehaus-plexus.github.io/plexus-maven-plugin/test-merge-descriptors-mojo.html" class="externalLink"><code>test-merge-descriptors</code></a></td>
+<td>see <code>testStaticMetadataDirectory</code> parameter  </td></tr>
<tr class="b">
-<th>source annotations</th>
-<td style="text-align: center;">javadoc tags:  <br /><code>@plexus.component</code>, <code>@plexus.requirement</code>, <code>@plexus.configuration</code>  </td>
-<td style="text-align: center;">javadoc tags + <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/"><code>plexus-component-annotations</code></a> Java 5 annotations: <br /><a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/apidocs/org/codehaus/plexus/component/annotations/Component.html"><code>@Component</code></a>, <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/apidocs/org/codehaus/plexus/component/annotations/Requirement.html"><code>@Requirement</code></a>, <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/apidocs/org/codehaus/plexus/component/annotations/Configuration.html"><code>@Configuration</code></a>,</td></tr></table></section><section>
-<h2>Recipe</h2><section>
-<h3>Plugin Configuration</h3>
+<td>default: <code>${basedir}/src/test/resources/META-INF/plexus</code></td></tr>
+<tr class="a">
+<td></td>
+<td><a href="https://codehaus-plexus.github.io/plexus-maven-plugin/components-report-mojo.html" class="externalLink"><code>components-report</code></a></td>
+<td>reporting feature not available</td></tr>
+<tr class="b">
+<td>source annotations</td>
+<td>javadoc tags:  </td></tr>
+<tr class="a">
+<td><code>@plexus.component</code>, <code>@plexus.requirement</code>, <code>@plexus.configuration</code>  </td>
+<td>javadoc tags + <a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/" class="externalLink"><code>plexus-component-annotations</code></a> Java 5 annotations: </td></tr>
+<tr class="b">
+<td><a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/apidocs/org/codehaus/plexus/component/annotations/Component.html" class="externalLink"><code>@Component</code></a>, <a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/apidocs/org/codehaus/plexus/component/annotations/Requirement.html" class="externalLink"><code>@Requirement</code></a>, <a href="https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/apidocs/org/codehaus/plexus/component/annotations/Configuration.html" class="externalLink"><code>@Configuration</code></a>,</td></tr></tbody>
+</table>
+</section><section>
+<h3>Recipe</h3><section>
+<h4>Plugin Configuration</h4>
<p>In your <code>pom.xml</code>, replace <code>plexus-maven-plugin</code> configuration:</p>
-<div class="source"><pre class="prettyprint linenums"><project>
+
+<div class="source"><pre class="prettyprint linenums"><code><project>
<build>
<plugins>
<plugin>
@@ -218,9 +250,11 @@
</executions>
</plugin>
</build>
-</project></pre></div>
+</project>
+</code></pre></div>
<p>with corresponding <code>plexus-component-metadata</code> configuration:</p>
-<div class="source"><pre class="prettyprint linenums"><project>
+
+<div class="source"><pre class="prettyprint linenums"><code><project>
<build>
<plugins>
<plugin>
@@ -236,11 +270,13 @@
</executions>
</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>
-<h3>Replacing Plexus Javadoc Tags with Plexus Java 5 Annotations</h3>
+</project>
+</code></pre></div>
+<p>If <code>merge-descriptors</code> is used, move the handwritten xml file to <code>$\{basedir\}/src/main/resources/META-INF/plexus</code>.</p></section><section>
+<h4>Replacing Plexus Javadoc Tags with Plexus Java 5 Annotations</h4>
<p>In your <code>pom.xml</code>, add <code>plexus-component-annotations</code> dependency:</p>
-<div class="source"><pre class="prettyprint linenums"><project>
+
+<div class="source"><pre class="prettyprint linenums"><code><project>
<dependencies>
<dependency>
<groupId>org.codehaus.plexus</groupId>
@@ -248,9 +284,11 @@
<version>1.7.1</version>
</dependency>
</dependencies>
-</project></pre></div>
+</project>
+</code></pre></div>
<p>In your java sources, replace javadoc tags:</p>
-<div class="source"><pre class="prettyprint linenums">/**
+
+<div class="source"><pre class="prettyprint linenums"><code>/**
* @plexus.component role="foo.MyComponent" role-hint="hint-value"
*/
public class MyComponentImplementation
@@ -260,9 +298,11 @@ public class MyComponentImplementation
* @plexus.requirement
*/
private InjectedComponent;
-}</pre></div>
+}
+</code></pre></div>
<p>with corresponding Java 5 annotations</p>
-<div class="source"><pre class="prettyprint linenums">import org.codehaus.plexus.component.annotations.Component;
+
+<div class="source"><pre class="prettyprint linenums"><code>import org.codehaus.plexus.component.annotations.Component;
import org.codehaus.plexus.component.annotations.Requirement;
@Component( role = MyComponent.class, hint = "hint-value" )
@@ -271,7 +311,8 @@ public class MyComponentImplementation
{
@Requirement
private InjectedComponent;
-}</pre></div></section></section></section>
+}
+</code></pre></div></section></section></section></section>
</main>
</div>
</div>
Modified: maven/website/content/plugin-developers/index.html
==============================================================================
--- maven/website/content/plugin-developers/index.html (original)
+++ maven/website/content/plugin-developers/index.html Thu Feb 9 00:34:05 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/apt/plugin-developers/index.apt at 2023-02-08
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/markdown/plugin-developers/index.md at 2023-02-09
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
@@ -48,8 +48,8 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/" class="externalLink" title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../index.html" title="Maven">Maven</a><span class="divider">/</span></li>
- <li class="active ">Plugin Developers Centre <a href="https://github.com/apache/maven-site/tree/master/content/apt/plugin-developers/index.apt"><img src="../images/accessories-text-editor.png" title="Edit" /></a></li>
- <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-08</li>
+ <li class="active ">Plugin Developers Centre <a href="https://github.com/apache/maven-site/tree/master/content/markdown/plugin-developers/index.md"><img src="../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-09</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../scm.html" title="Get Sources">Get Sources</a></li>
<li class="pull-right"><a href="../download.cgi" title="Download">Download</a></li>
@@ -136,29 +136,70 @@
</div>
</header>
<main id="bodyColumn" class="span10" >
-<section>
-<h1>Plugin Developers Centre</h1>
-<p>This documentation centre is for those who are developing Maven plugins. This might be for your own build, or as an accompaniment to your third party tool.</p>
-<p><b>What is a Mojo?</b> A mojo is a <b>M</b>aven plain <b>O</b>ld <b>J</b>ava <b>O</b>bject. Each mojo is an executable <i>goal</i> in Maven, and a plugin is a distribution of one or more related mojos.</p>
+<!--
+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.
+-->
+<section><section>
+<h2>Plugin Developers Centre</h2>
+<p>This documentation centre is for those who are developing Maven plugins. This might be for your own build, or as an accompaniment to your third party tool.</p><!-- TODO: callout -->
+
+<p><strong>What is a Mojo?</strong> A mojo is a <strong>M</strong>aven plain <strong>O</strong>ld <strong>J</strong>ava <strong>O</strong>bject. Each mojo is an executable <em>goal</em> in Maven, and a plugin is a distribution of one or more related mojos.</p><!-- TODO: tasks as buttons? -->
+
<ul>
-<li><a href="../guides/introduction/introduction-to-plugins.html"> Introduction to Plugin Development</a> - Introduction to concepts</li>
-<li><a href="../guides/plugin/guide-java-plugin-development.html"> Your First Mojo</a> - Learn how to write your first plugin</li>
-<li><a href="../guides/plugin/guide-java-report-plugin-development.html"> Your First Report Mojo</a> - Learn how to write your first reporting plugin</li>
-<li><a href="./plugin-testing.html"> Testing your Plugin</a> - How to write tests for your plugins</li>
-<li><a href="./plugin-documenting.html"> Documenting your Plugin</a> - How to write documentation for your plugins</li>
-<li>TODO: creating and using custom packaging (like <a href="/archetype/archetype-packaging/"><code>maven-archetype</code> packaging</a>)</li>
-<li><a href="./common-bugs.html"> Common Bugs and Pitfalls</a> - Overview of problematic coding patterns</li></ul><section>
-<h2>Reference</h2>
+
+<li>
+<p><a href="../guides/introduction/introduction-to-plugins.html">Introduction to Plugin Development</a> - Introduction to concepts</p></li>
+<li>
+<p><a href="../guides/plugin/guide-java-plugin-development.html">Your First Mojo</a> - Learn how to write your first plugin</p></li>
+<li>
+<p><a href="../guides/plugin/guide-java-report-plugin-development.html">Your First Report Mojo</a> - Learn how to write your first reporting plugin</p></li>
+<li>
+<p><a href="./plugin-testing.html">Testing your Plugin</a> - How to write tests for your plugins</p></li>
+<li>
+<p><a href="./plugin-documenting.html">Documenting your Plugin</a> - How to write documentation for your plugins</p></li>
+<li>
+<p>TODO: creating and using custom packaging (like <a href="/archetype/archetype-packaging/"><code>maven-archetype</code> packaging</a>)</p></li>
+<li>
+<p><a href="./common-bugs.html">Common Bugs and Pitfalls</a> - Overview of problematic coding patterns</p></li>
+</ul><!-- TODO: trails -->
+<section>
+<h3>Reference</h3>
<ul>
-<li><a href="../developers/mojo-api-specification.html"> Mojo API and Annotation Reference</a></li>
-<li><a href="/plugin-tools/examples/using-annotations.html"> Maven Plugin Tools and annotations</a></li>
-<li><a href="../ref/current/index.html"> Maven API Reference</a></li>
-<li><a href="../guides/mini/guide-maven-classloading.html"> Maven Class Loading</a></li></ul></section><section>
-<h2>Extensions</h2>
+
+<li>
+<p><a href="../developers/mojo-api-specification.html">Mojo API and Annotation Reference</a></p></li>
+<li>
+<p><a href="/plugin-tools/examples/using-annotations.html">Maven Plugin Tools and annotations</a></p></li>
+<li>
+<p><a href="../ref/current/index.html">Maven API Reference</a></p></li>
+<li>
+<p><a href="../guides/mini/guide-maven-classloading.html">Maven Class Loading</a></p></li>
+</ul></section><section>
+<h3>Extensions</h3>
<ul>
-<li><a href="../examples/maven-3-lifecycle-extensions.html">Maven 3 lifecycle extensions</a></li>
-<li><a href="./cookbook/plexus-plugin-upgrade.html">How to upgrade from Plexus javadoc tags to Plexus Java annotations?</a></li>
-<li><a href="/maven-jsr330.html">Using JSR-330 (instead of Plexus Java annotations)</a></li></ul></section></section>
+
+<li>
+<p><a href="../examples/maven-3-lifecycle-extensions.html">Maven 3 lifecycle extensions</a></p></li>
+<li>
+<p><a href="./cookbook/plexus-plugin-upgrade.html">How to upgrade from Plexus javadoc tags to Plexus Java annotations?</a></p></li>
+<li>
+<p><a href="/maven-jsr330.html">Using JSR-330 (instead of Plexus Java annotations)</a></p></li>
+</ul></section></section></section>
</main>
</div>
</div>
Modified: maven/website/content/plugin-developers/plugin-documenting.html
==============================================================================
--- maven/website/content/plugin-developers/plugin-documenting.html (original)
+++ maven/website/content/plugin-developers/plugin-documenting.html Thu Feb 9 00:34:05 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/apt/plugin-developers/plugin-documenting.apt at 2023-02-08
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/markdown/plugin-developers/plugin-documenting.md at 2023-02-09
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
@@ -48,8 +48,8 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/" class="externalLink" title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../index.html" title="Maven">Maven</a><span class="divider">/</span></li>
- <li class="active ">Developers centre - Documentation Plugins Strategies <a href="https://github.com/apache/maven-site/tree/master/content/apt/plugin-developers/plugin-documenting.apt"><img src="../images/accessories-text-editor.png" title="Edit" /></a></li>
- <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-08</li>
+ <li class="active ">Developers centre - Documentation Plugins Strategies <a href="https://github.com/apache/maven-site/tree/master/content/markdown/plugin-developers/plugin-documenting.md"><img src="../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-09</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../scm.html" title="Get Sources">Get Sources</a></li>
<li class="pull-right"><a href="../download.cgi" title="Download">Download</a></li>
@@ -136,17 +136,38 @@
</div>
</header>
<main id="bodyColumn" class="span10" >
-<section>
-<h1>Introduction</h1>
+<!--
+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.
+-->
+<section><section>
+<h2>Introduction</h2>
<p>A <a href="../guides/development/guide-plugin-documentation.html">Guide to the Plugin Documentation Standard</a> was created. This document is intended to verify it during the Plugins development.</p></section><section>
-<h1>Verify Plugin Documentation</h1>
+<h2>Verify Plugin Documentation</h2>
<p>The <a href="../plugins/maven-docck-plugin">maven-docck-plugin</a> checks that a project complies with the Plugin Documentation Standard.</p>
-<p>You <b>should</b> verify that all Plugin documentation respects this standard. The maven-docck-plugin can be run:</p>
-<div>
-<pre>mvn docck:check</pre></div></section><section>
-<h1>References</h1>
+<p>You <strong>should</strong> verify that all Plugin documentation respects this standard. The maven-docck-plugin can be run:</p>
+
+<div class="source"><pre class="prettyprint linenums"><code>mvn docck:check
+</code></pre></div></section><section>
+<h2>References</h2>
<ul>
-<li><a class="externalLink" href="http://cwiki.apache.org/confluence/display/MAVENOLD/Maven+Plugin+Documentation">Maven Plugin Documentation</a></li></ul></section>
+
+<li><a href="http://cwiki.apache.org/confluence/display/MAVENOLD/Maven+Plugin+Documentation" class="externalLink">Maven Plugin Documentation</a></li>
+</ul></section></section>
</main>
</div>
</div>
Modified: maven/website/content/plugin-developers/plugin-testing.html
==============================================================================
--- maven/website/content/plugin-developers/plugin-testing.html (original)
+++ maven/website/content/plugin-developers/plugin-testing.html Thu Feb 9 00:34:05 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/apt/plugin-developers/plugin-testing.apt at 2023-02-08
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from content/markdown/plugin-developers/plugin-testing.md at 2023-02-09
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
@@ -11,8 +11,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M4" />
<meta name="author" content="Vincent Siveton" />
- <meta name="date" content="2008-01-01
-2015-06-16" />
+ <meta name="date" content="2008-01-01, 2015-06-16" />
<title>Maven – Developers centre - Testing Plugins Strategies</title>
<link rel="stylesheet" href="../css/apache-maven-fluido-1.11.1.min.css" />
<link rel="stylesheet" href="../css/site.css" />
@@ -49,8 +48,8 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/" class="externalLink" title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../index.html" title="Maven">Maven</a><span class="divider">/</span></li>
- <li class="active ">Developers centre - Testing Plugins Strategies <a href="https://github.com/apache/maven-site/tree/master/content/apt/plugin-developers/plugin-testing.apt"><img src="../images/accessories-text-editor.png" title="Edit" /></a></li>
- <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-08</li>
+ <li class="active ">Developers centre - Testing Plugins Strategies <a href="https://github.com/apache/maven-site/tree/master/content/markdown/plugin-developers/plugin-testing.md"><img src="../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2023-02-09</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../scm.html" title="Get Sources">Get Sources</a></li>
<li class="pull-right"><a href="../download.cgi" title="Download">Download</a></li>
@@ -137,25 +136,45 @@
</div>
</header>
<main id="bodyColumn" class="span10" >
-<section>
-<h1>Introduction</h1>
-<p>Currently, Maven only supports unit testing out of the box. This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests.</p></section><section>
-<h1>Testing Styles: Unit Testing vs. Functional/Integration Testing</h1>
+<!--
+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.
+-->
+<section><section>
+<h2>Introduction</h2>
+<p>Currently, Maven only supports unit testing out of the box. This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests.</p><!-- <<Note: There are a lot of different ways to test a Maven plugin.>> For a review of different strategies and tools, please refer to {{{http://docs.codehaus.org/display/MAVENUSER/Review+of+Plugin+Testing+Strategies}Review of Plugin Testing Strategies}} -->
+</section><section>
+<h2>Testing Styles: Unit Testing vs. Functional/Integration Testing</h2>
<p>A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast.</p>
<p>A functional/integration test attempts to use a mojo in a real Maven build, by launching a real instance of Maven in a real project. Normally this requires you to construct special dummy Maven projects with real POM files. Often this requires you to have already installed your plugin into your local repository so it can be used in a real Maven build. Functional tests run much more slowly than unit tests, but they can catch bugs that you may not catch with unit tests.</p>
<p>The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests.</p></section><section>
-<h1>Unit Tests</h1><section>
-<h2>Using JUnit alone</h2>
+<h2>Unit Tests</h2><section>
+<h3>Using JUnit alone</h3>
<p>In principle, you can write a unit test of a plugin Mojo the same way you'd write any other JUnit test case, by writing a class that <code>extends TestCase</code>.</p>
<p>However, most mojos need more information to work properly. For example, you'll probably need to inject a reference to a MavenProject, so your mojo can query project variables.</p></section><section>
-<h2>Using PlexusTestCase</h2>
+<h3>Using PlexusTestCase</h3>
<p>Mojo variables are injected using Plexus, and many Mojos are written to take specific advantage of the Plexus container (by executing a lifecycle or having various injected dependencies).</p>
<p>If all you need are Plexus container services, you can write your class with <code>extends PlexusTestCase</code> instead of TestCase.</p>
<p>With that said, if you need to inject Maven objects into your mojo, you'll probably prefer to use the maven-plugin-testing-harness.</p></section><section>
-<h2>maven-plugin-testing-harness</h2>
+<h3>maven-plugin-testing-harness</h3>
<p>The <a href="/plugin-testing/maven-plugin-testing-harness/">maven-plugin-testing-harness</a> is explicitly intended to test the <code>org.apache.maven.reporting.AbstractMavenReport#execute()</code> implementation.</p>
<p>In general, you need to include <code>maven-plugin-testing-harness</code> as a dependency, and create a *MojoTest (by convention) class which <code>extends AbstractMojoTestCase</code>.</p>
-<div class="source"><pre class="prettyprint linenums">...
+
+<div class="source"><pre class="prettyprint linenums"><code>...
<dependencies>
...
<dependency>
@@ -166,8 +185,10 @@
</dependency>
...
</dependencies>
-...</pre></div>
-<div class="source"><pre class="prettyprint linenums">public class YourMojoTest
+...
+</code></pre></div>
+
+<div class="source"><pre class="prettyprint linenums"><code>public class YourMojoTest
extends AbstractMojoTestCase
{
/**
@@ -191,17 +212,19 @@
assertNotNull( mojo );
}
-}</pre></div>
-<p>For more information, refer to <a class="externalLink" href="http://cwiki.apache.org/confluence/display/MAVENOLD/Maven+Plugin+Harness">Maven Plugin Harness Wiki</a></p></section></section><section>
-<h1>Integration/Functional testing</h1><section>
-<h2>maven-verifier</h2>
+}
+</code></pre></div>
+<p>For more information, refer to <a href="http://cwiki.apache.org/confluence/display/MAVENOLD/Maven+Plugin+Harness" class="externalLink">Maven Plugin Harness Wiki</a></p></section></section><section>
+<h2>Integration/Functional testing</h2><section>
+<h3>maven-verifier</h3>
<p>maven-verifier tests are run using JUnit or TestNG, and provide a simple class allowing you to launch Maven and assert on its log file and built artifacts. It also provides a ResourceExtractor, which extracts a Maven project from your src/test/resources directory into a temporary working directory where you can do tricky stuff with it. Follow the <a href="/shared/maven-verifier/getting-started.html">Getting Started</a> guide to learn more about creating maven-verifier tests.</p>
-<p>Maven itself uses maven-verifier to run its core integration tests. For more information, please refer to <a class="externalLink" href="https://cwiki.apache.org/confluence/display/MAVEN/Creating+a+Maven+Integration+Test">Creating a Maven Integration Test</a>.</p>
-<p><b>Note</b>: maven-verifier and maven-verifier-plugin sound similar, but are totally different unrelated pieces of code. maven-verifier-plugin simply verifies the existence/absence of files on the filesystem. You could use it for functional testing, but you may need more features than maven-verifier-plugin provides.</p></section><section>
-<h2>maven-invoker-plugin</h2>
-<p>You can use <a class="externalLink" href="https://maven.apache.org/plugins/maven-invoker-plugin/">maven-invoker-plugin</a> to invoke Maven and to provide some BeanShell/Groovy tests. Tests written in this way don't run under JUnit/TestNG; instead, they're run by Maven itself.</p>
-<p>You can take a look at the <a class="externalLink" href="https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/it/">maven-install-plugin</a> how there are integration tests are written.</p>
-<div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+<p>Maven itself uses maven-verifier to run its core integration tests. For more information, please refer to <a href="https://cwiki.apache.org/confluence/display/MAVEN/Creating+a+Maven+Integration+Test" class="externalLink">Creating a Maven Integration Test</a>.</p>
+<p><strong>Note</strong>: maven-verifier and maven-verifier-plugin sound similar, but are totally different unrelated pieces of code. maven-verifier-plugin simply verifies the existence/absence of files on the filesystem. You could use it for functional testing, but you may need more features than maven-verifier-plugin provides.</p></section><section>
+<h3>maven-invoker-plugin</h3>
+<p>You can use <a href="https://maven.apache.org/plugins/maven-invoker-plugin/" class="externalLink">maven-invoker-plugin</a> to invoke Maven and to provide some BeanShell/Groovy tests. Tests written in this way don't run under JUnit/TestNG; instead, they're run by Maven itself.</p>
+<p>You can take a look at the <a href="https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/it/" class="externalLink">maven-install-plugin</a> how there are integration tests are written.</p>
+
+<div class="source"><pre class="prettyprint linenums"><code><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
<build>
@@ -229,7 +252,8 @@
</plugins>
</build>
...
-</project></pre></div></section></section>
+</project>
+</code></pre></div></section></section></section>
</main>
</div>
</div>