Modified: maven/website/content/plugins/localization.html ============================================================================== --- maven/website/content/plugins/localization.html (original) +++ maven/website/content/plugins/localization.html Sat Aug 20 12:41:42 2022 @@ -2,14 +2,14 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 1.11.1 from content/apt/plugins/localization.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/plugins/localization.apt at 2022-08-20 | Rendered using Apache Maven Fluido Skin 1.11.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> - <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" /> + <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" /> <meta name="author" content="Dennis Lundberg Vincent Siveton" /> <meta name="date" content="2012-03-12" /> @@ -125,7 +125,7 @@ Vincent Siveton" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Localization_of_Plugins"></a>Localization of Plugins</h2> +<h1><a name="Localization_of_Plugins"></a>Localization of Plugins</h1> <p>Most of the plugins involved with the site generation are fully internationalized. This means that adapting them to another language, a process known as localization, is very easy. All that is needed is to download a couple of properties files and start translating the texts in them. If you want to provide a patch for an unsupported language, there are detailed instructions below.</p> <p>For the basic site generation there are currently files for three components that needs to be localized to support a new language: Maven Site Plugin, Maven Project Info Reports Plugin and Maven Doxia Tools.</p> <p><b>Note:</b> The links to SVN below goes to the latest development code. So the files may be newer than the ones included in the latest release.</p> @@ -510,7 +510,7 @@ Vincent Siveton" /> <td align="left"><a href="/plugins/maven-site-plugin/l10n-status.html">l10n report</a></td> <td align="left"><a class="externalLink" href="https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-site-plugin/src/main/resources/";>SVN</a></td></tr></table> <p>Is your favourite plugin missing a localization for your language? Please help us expand the language support by following the instructions below.</p><section> -<h3><a name="Localizing_a_Plugin"></a>Localizing a Plugin</h3> +<h2><a name="Localizing_a_Plugin"></a>Localizing a Plugin</h2> <ul> <li>Check out the source code for the plugin you want to add a translation to.</li> <li>Find the resource bundles that needs to be translated. They are often found in the <code>src/main/resources</code> folder.</li> @@ -535,25 +535,25 @@ Vincent Siveton" /> <li>Create a patch file that contains your new translation. Use the issue number when you name the file: <div class="source"><pre class="prettyprint linenums">svn diff > MYISSUE-123.patch</pre></div></li> <li>Attach your patch file to the issue in JIRA.</li></ul></section><section> -<h3><a name="Tools"></a>Tools</h3> +<h2><a name="Tools"></a>Tools</h2> <p>There is a command line tool called <b>native2ascii</b> that can be used to convert a text file to use Unicode-encoded characters instead of native-encoded characters. This is part of the Java SDK and you can <a class="externalLink" href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/native2ascii.html";>read more about it here</a>. You use it like this:</p> <div class="source"><pre class="prettyprint linenums">native2ascii checkstyle-report_es.properties checkstyle-report_es-encoded.properties</pre></div><section> -<h4><a name="Tools_to_find_out_the_charset_of_a_file"></a>Tools to find out the charset of a file</h4> +<h3><a name="Tools_to_find_out_the_charset_of_a_file"></a>Tools to find out the charset of a file</h3> <ul> <li>Unix <code>file</code> command</li> <li><a class="externalLink" href="http://cpdetector.sourceforge.net/";>cpdetector</a></li> <li><a class="externalLink" href="http://plugins.intellij.net/plugin/?id=24";>IntelliJ IDEA ShowEncodingPlugin</a></li> <li><a class="externalLink" href="http://notepad-plus.sourceforge.net/";>Notepad++</a></li></ul></section><section> -<h4><a name="Tools_to_write_a_file_in_a_given_charset"></a>Tools to write a file in a given charset</h4> +<h3><a name="Tools_to_write_a_file_in_a_given_charset"></a>Tools to write a file in a given charset</h3> <p>Any editor like Notepad++, Eclipse, IntelliJ IDEA, ...</p></section><section> -<h4><a name="Tools_to_convert_a_file_from_one_encoding_to_another_encoding"></a>Tools to convert a file from one encoding to another encoding</h4> +<h3><a name="Tools_to_convert_a_file_from_one_encoding_to_another_encoding"></a>Tools to convert a file from one encoding to another encoding</h3> <ul> <li>Unix <code>iconv</code> command</li> <li>Notepad++</li></ul></section><section> -<h4><a name="IDE_plugins"></a>IDE plugins</h4> +<h3><a name="IDE_plugins"></a>IDE plugins</h3> <ul> <li><a class="externalLink" href="http://propedit.sourceforge.jp/index_en.html";>Properties Editor Eclipse Plugin</a></li></ul></section></section><section> -<h3><a name="References"></a>References</h3> +<h2><a name="References"></a>References</h2> <p>Please refer to the <a class="externalLink" href="http://java.sun.com/javase/technologies/core/basic/intl/";>Java Internationalization home page</a> for an introduction to the topic.</p> <p>You can also refer to this Sun FAQ: <a class="externalLink" href="http://developers.sun.com/global/technology/standards/reference/faqs/determining-file-encoding.html";>How Can I Determine the Encoding of a File?</a></p></section></section> </main>
Modified: maven/website/content/pom.html ============================================================================== --- maven/website/content/pom.html (original) +++ maven/website/content/pom.html Sat Aug 20 12:41:42 2022 @@ -2,14 +2,14 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 1.11.1 from content/apt/pom.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/pom.apt at 2022-08-20 | Rendered using Apache Maven Fluido Skin 1.11.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> - <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" /> + <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" /> <meta name="author" content="Eric Redmond, et al. Karl Heinz Marbaise" /> <meta name="date" content="2019-12-31" /> @@ -139,7 +139,7 @@ Karl Heinz Marbaise" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="POM_Reference"></a>POM Reference</h2> +<h1><a name="POM_Reference"></a>POM Reference</h1> <ol style="list-style-type: decimal"> <li><a href="#Introduction">Introduction</a> <ol style="list-style-type: decimal"> @@ -208,12 +208,12 @@ Karl Heinz Marbaise" /> <li><a href="#Activation">Activation</a></li> <li><a href="#The_BaseBuild_Element_Set">The BaseBuild Element Set <i>(revisited)</i></a></li></ol></li></ol></li> <li><a href="#Final">Final</a></li></ol></section><section> -<h2><a name="Introduction">Introduction</a></h2> +<h1><a name="Introduction">Introduction</a></h1> <ul> <li><a href="/xsd/maven-4.0.0.xsd">The POM 4.0.0 XSD</a> and <a href="/ref/current/maven-model/maven.html">descriptor reference documentation</a></li></ul><section> -<h3><a name="What_is_the_POM.3F"></a><a name="What_is_the_POM">What is the POM?</a></h3> +<h2><a name="What_is_the_POM.3F"></a><a name="What_is_the_POM">What is the POM?</a></h2> <p>POM stands for "Project Object Model". It is an XML representation of a Maven project held in a file named <code>pom.xml</code>. When in the presence of Maven folks, speaking of a project is speaking in the philosophical sense, beyond a mere collection of files containing code. A project contains configuration files, as well as the developers involved and the roles they play, the defect tracking system, the organization and licenses, the URL of where the project lives, the project's dependencies, and all of the other little pieces that come into play to give code life. It is a one-stop-shop for all things concerning the project. In fact, in the Maven world, a project does not need to contain any code at all, merely a <code>pom.xml</code>.</p></section><section> -<h3><a name="Quick_Overview">Quick Overview</a></h3> +<h2><a name="Quick_Overview">Quick Overview</a></h2> <p>This is a listing of the elements directly under the POM's project element. Notice that <code>modelVersion</code> contains 4.0.0. That is currently the only supported POM version, and is always required.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -255,7 +255,7 @@ Karl Heinz Marbaise" /> <distributionManagement>...</distributionManagement> <profiles>...</profiles> </project></pre></div></section></section><section> -<h2><a name="The_Basics">The Basics</a></h2> +<h1><a name="The_Basics">The Basics</a></h1> <p>The POM contains all necessary information about a project, as well as configurations of plugins to be used during the build process. It is the declarative manifestation of the "who", "what", and "where", while the build lifecycle is the "when" and "how". That is not to say that the POM cannot affect the flow of the lifecycle - it can. For example, by configuring the <code>maven-antrun-plugin</code>, one can embed Apache Ant tasks inside of the POM. It is ultimately a declaration, however. Whereas a <code>build.xml</code> tells Ant precisely what to do when it is run (procedural), a POM states its configuration (declarative). If some external force causes the lifecycle to skip the Ant plugin execution, it does not stop the plugins that are executed from doing their magic. This is unlike a <code>build.xml</code> file, where tasks are almost always dependant on the lines executed before it.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -265,14 +265,14 @@ Karl Heinz Marbaise" /> <artifactId>my-project</artifactId> <version>1.0</version> </project></pre></div><section> -<h3><a name="Maven_Coordinates">Maven Coordinates</a></h3> +<h2><a name="Maven_Coordinates">Maven Coordinates</a></h2> <p>The POM defined above is the bare minimum that Maven allows. <code>groupId:artifactId:version</code> are all required fields (although, groupId and version do not need to be explicitly defined if they are inherited from a parent - more on inheritance later). The three fields act much like an address and timestamp in one. This marks a specific place in a repository, acting like a coordinate system for Maven projects:</p> <ul> <li><b>groupId</b>: This is generally unique amongst an organization or a project. For example, all core Maven artifacts do (well, should) live under the groupId <code>org.apache.maven</code>. Group ID's do not necessarily use the dot notation, for example, the junit project. Note that the dot-notated groupId does not have to correspond to the package structure that the project contains. It is, however, a good practice to follow. When stored within a repository, the group acts much like the Java packaging structure does in an operating system. The dots are replaced by OS specific directory separators (such as '/' in Unix) which becomes a relative directory structure from the base repository. In the example given, the <code>org.codehaus.mojo</code> group lives within the directory <code>$M2_REPO/org/codehaus/mojo</code>.</li> <li><b>artifactId</b>: The artifactId is generally the name that the project is known by. Although the groupId is important, people within the group will rarely mention the groupId in discussion (they are often all be the same ID, such as the <a class="externalLink" href="http://www.mojohaus.org/";>MojoHaus</a> project groupId: <code>org.codehaus.mojo</code>). It, along with the groupId, creates a key that separates this project from every other project in the world (at least, it should :) ). Along with the groupId, the artifactId fully defines the artifact's living quarters within the repository. In the case of the above project, <code>my-project</code> lives in <code>$M2_REPO/org/codehaus/mojo/my-project</code>.</li> <li><b>version</b>: This is the last piece of the naming puzzle. <code>groupId:artifactId</code> denotes a single project but they cannot delineate which incarnation of that project we are talking about. Do we want the <code>junit:junit</code> of 2018 (version 4.12), or of 2007 (version 3.8.2)? In short: code changes, those changes should be versioned, and this element keeps those versions in line. It is also used within an artifact's repository to separate versions from each other. <code>my-project</code> version 1.0 files live in the directory structure <code>$M2_REPO/org/codehaus/mojo/my-project/1.0</code>.</li></ul> <p>The three elements given above point to a specific version of a project, letting Maven know <i>who</i> we are dealing with, and <i>when</i> in its software lifecycle we want them.</p></section><section> -<h3><a name="packaging"></a><b>packaging</b></h3> +<h2><a name="packaging"></a><b>packaging</b></h2> <p>Now that we have our address structure of <code>groupId:artifactId:version</code>, there is one more standard label to give us a really complete <i>what</i>: that is the project's packaging. In our case, the example POM for <code>org.codehaus.mojo:my-project:1.0</code> defined above will be packaged as a <code>jar</code>. We could make it into a <code>war</code> by declaring a different packaging:</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -281,11 +281,11 @@ Karl Heinz Marbaise" /> ... </project></pre></div> <p>When no packaging is declared, Maven assumes the packaging is the default: <code>jar</code>. The valid types are Plexus role-hints (read more on Plexus for a explanation of roles and role-hints) of the component role <code>org.apache.maven.lifecycle.mapping.LifecycleMapping</code>. The current core packaging values are: <code>pom</code>, <code>jar</code>, <code>maven-plugin</code>, <code>ejb</code>, <code>war</code>, <code>ear</code>, <code>rar</code>. These define the default list of goals which execute on each corresponding build lifecycle stage for a particular package structure: see <a href="/ref/current/maven-core/default-bindings.html">Plugin Bindings for default Lifecycle Reference</a> for details.</p></section><section> -<h3><a name="POM_Relationships">POM Relationships</a></h3> +<h2><a name="POM_Relationships">POM Relationships</a></h2> <p>One powerful aspect of Maven is its handling of project relationships: this includes dependencies (and transitive dependencies), inheritance, and aggregation (multi-module projects).</p> <p>Dependency management has a long tradition of being a complicated mess for anything but the most trivial of projects. <i>"Jarmageddon"</i> quickly ensues as the dependency tree becomes large and complicated. <i>"Jar Hell"</i> follows, where versions of dependencies on one system are not equivalent to the versions developed with, either by the wrong version given, or conflicting versions between similarly named jars.</p> <p>Maven solves both problems through a common local repository from which to link projects correctly, versions and all.</p><section> -<h4><a name="Dependencies">Dependencies</a></h4> +<h3><a name="Dependencies">Dependencies</a></h3> <p>The cornerstone of the POM is its <a href="/ref/current/maven-model/maven.html#class_dependency">dependency</a> list. Most projects depend on others to build and run correctly. If all Maven does for you is manage this list, you have gained a lot. Maven downloads and links the dependencies on compilation, as well as on other goals that require them. As an added bonus, Maven brings in the dependencies of those dependencies (transitive dependencies), allowing your list to focus solely on the dependencies your project requires.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -331,7 +331,7 @@ Karl Heinz Marbaise" /> <li><b>systemPath</b>:<br />is used <i>only</i> if the dependency <code>scope</code> is <code>system</code>. Otherwise, the build will fail if this element is set. The path must be absolute, so it is recommended to use a property to specify the machine-specific path (more on <code>properties</code> below), such as <code>${java.home}/lib</code>. Since it is assumed that system scope dependencies are installed <i>a priori</i>, Maven does not check the repositories for the project, but instead checks to ensure that the file exists. If not, Maven fails the build and suggests that you download and install it manually.</li> <li><b>optional</b>:<br />Marks a dependency optional when this project itself is a dependency. For example, imagine a project <code>A</code> that depends upon project <code>B</code> to compile a portion of code that may not be used at runtime, then we may have no need for project <code>B</code> for all project. So if project <code>X</code> adds project <code>A</code> as its own dependency, then Maven does not need to install project <code>B</code> at all. Symbolically, if <code>=></code> represents a required dependency, and <code>--></code> represents optional, although <code>A=>B</code> may be the case when building A <code>X=>A-->B</code> would be the case when building <code>X</code>. <p>In the shortest terms, <code>optional</code> lets other projects know that, when you use this project, you do not require this dependency in order to work correctly.</p></li></ul><section> -<h5><a name="Dependency_Version_Requirement_Specification">Dependency Version Requirement Specification</a></h5> +<h4><a name="Dependency_Version_Requirement_Specification">Dependency Version Requirement Specification</a></h4> <p>Dependencies' <code>version</code> elements define version requirements, which are used to compute dependency versions. Soft requirements can be replaced by different versions of the same artifact found elsewhere in the dependency graph. Hard requirements mandate a particular version or versions and override soft requirements. If there are no versions of a dependency that satisfy all the hard requirements for that artifact, the build fails.</p> <p>Version requirements have the following syntax:</p> <ul> @@ -344,7 +344,7 @@ Karl Heinz Marbaise" /> <li><code>(,1.0],[1.2,)</code>: Hard requirement for any version less than or equal to 1.0 than or greater than or equal to 1.2, but not 1.1. Multiple requirements are separated by commas.</li> <li><code>(,1.1),(1.1,)</code>: Hard requirement for any version except 1.1; for example because 1.1 has a critical vulnerability. <p>Maven picks the highest version of each project that satisfies all the hard requirements of the dependencies on that project. If no version satisfies all the hard requirements, the build fails.</p></li></ul></section><section> -<h5><a name="Version_Order_Specification:"></a><a name="Version_Order_Specification">Version Order Specification</a>:</h5> +<h4><a name="Version_Order_Specification:"></a><a name="Version_Order_Specification">Version Order Specification</a>:</h4> <p>If version strings are syntactically correct <a class="externalLink" href="https://semver.org/spec/v1.0.0.html";>Semantic Versioning 1.0.0</a> version numbers, then in almost all cases version comparison follows the precedence rules outlined in that specification. These versions are the commonly encountered alphanumeric ASCII strings such as 2.15.2-alpha. More precisely, this is true if both version numbers to be compared match the "valid semver" production in the BNF grammar in the semantic versioning specification. Maven does not consider any semantics implied by that specification.</p> <p><b>Important</b>: This is only true for Semantic Versioning <i>1.0.0</i>. The Maven version order algorithm is not compatible with Semantic Versioning <i>2.0.0</i>. In particular, Maven does not special case the plus sign or consider build identifiers.</p> <p>When version strings do not follow semantic versioning, a more complex set of rules is required. The Maven coordinate is split in tokens between dots ('<code>.</code>'), hyphens ('<code>-</code>') and transitions between digits and characters. The separator is recorded and will have effect on the order. A transition between digits and characters is equivalent to a hyphen. Empty tokens are replaced with "<code>0</code>". This gives a sequence of version numbers (numeric tokens) and version qualifiers (non-numeric tokens) with "<code>.</code>" or "<code>-</code>" prefixes.</p> @@ -385,7 +385,7 @@ Karl Heinz Marbaise" /> <li>"<code>1-a1</code>" = "<code>1-alpha-1</code>" <p>Note: Contrary to what was stated in some design documents, for version order, snapshots are not treated differently than releases or any other qualifier.</p> <p>Note: As <code>2.0-rc1</code> < <code>2.0</code>, the version requirement <code>[1.0,2.0)</code> excludes <code>2.0</code> but includes version <code>2.0-rc1</code>, which is contrary to what most people expect. In addition, Gradle interprets it differently, resulting in different dependency trees for the same POM. If the intention is to restrict it to <i>1.*</i> versions, the better version requirement is <code>[1,1.999999)</code>.</p></li></ul></section><section> -<h5><a name="Version_Order_Testing:"></a><a name="Version_Order_Testing">Version Order Testing</a>:</h5> +<h4><a name="Version_Order_Testing:"></a><a name="Version_Order_Testing">Version Order Testing</a>:</h4> <p>The maven distribution includes a tool to check version order. It was used to produce the examples in the previous paragraphs. Feel free to run it yourself when in doubt. You can run it like this:</p> <div> <pre>java -jar ${MAVEN_HOME}/lib/maven-artifact-3.3.9.jar [versions...]</pre></div> @@ -398,7 +398,7 @@ Display parameters as parsed by Maven (i 2. 2 == 2 2 > 1.1 3. 1.1 == 1.1</pre></div></section><section> -<h5><a name="Exclusions">Exclusions</a></h5> +<h4><a name="Exclusions">Exclusions</a></h4> <p>Exclusions tell Maven not to include the specified project that is a dependency of this dependency (in other words, its transitive dependency). For example, the <code>maven-embedder</code> requires <code>maven-core</code>, and we do not wish to use it or its dependencies, then we would add it as an <code>exclusion</code>.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -441,7 +441,7 @@ Display parameters as parsed by Maven (i </project></pre></div> <ul> <li><b>exclusions</b>: Exclusions contain one or more <code>exclusion</code> elements, each containing a <code>groupId</code> and <code>artifactId</code> denoting a dependency to exclude. Unlike <code>optional</code>, which may or may not be installed and used, <code>exclusions</code> actively remove themselves from the dependency tree.</li></ul></section></section><section> -<h4><a name="Inheritance">Inheritance</a></h4> +<h3><a name="Inheritance">Inheritance</a></h3> <p>One powerful addition that Maven brings to build management is the concept of project inheritance. Although in build systems such as Ant inheritance can be simulated, Maven makes project inheritance explicit in the project object model.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -499,7 +499,7 @@ Display parameters as parsed by Maven (i </project></pre></div> <p>Notice the <code>relativePath</code> element. It is not required, but may be used as a signifier to Maven to first search the path given for this project's parent, before searching the local and then remote repositories.</p> <p>To see inheritance in action, just have a look at the <a class="externalLink" href="https://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?view=markup";>ASF</a> or <a class="externalLink" href="https://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?view=markup";>Maven</a> parent POM's.</p><section> -<h5><a name="The_Super_POM">The Super POM</a></h5> +<h4><a name="The_Super_POM">The Super POM</a></h4> <p>Similar to the inheritance of objects in object oriented programming, POMs that extend a parent POM inherit certain values from that parent. Moreover, just as Java objects ultimately inherit from <code>java.lang.Object</code>, all Project Object Models inherit from a base Super POM. The snippet below is the Super POM for Maven 3.5.4.</p> <div class="source"><pre class="prettyprint linenums"><project> <modelVersion>4.0.0</modelVersion> @@ -630,12 +630,12 @@ Display parameters as parsed by Maven (i </project> </pre></div> <p>You can take a look at how the Super POM affects your Project Object Model by creating a minimal <code>pom.xml</code> and executing on the command line: <code>mvn help:effective-pom</code></p></section><section> -<h5><a name="Dependency_Management">Dependency Management</a></h5> +<h4><a name="Dependency_Management">Dependency Management</a></h4> <p>Besides inheriting certain top-level elements, parents have elements to configure values for child POMs and transitive dependencies. One of those elements is <code>dependencyManagement</code>.</p> <ul> <li><b>dependencyManagement</b>: is used by a POM to help manage dependency information across all of its children. If the <code>my-parent</code> project uses <code>dependencyManagement</code> to define a dependency on <code>junit:junit:4.12</code>, then POMs inheriting from this one can set their dependency giving the <code>groupId</code>=<code>junit</code> and <code>artifactId</code>=<code>junit</code> only and Maven will fill in the <code>version</code> set by the parent. The benefits of this method are obvious. Dependency details can be set in one central location, which propagates to all inheriting POMs. <p>Note that the version and scope of artifacts which are incorporated from transitive dependencies are also controlled by version specifications in a dependency management section. This can lead to unexpected consequences. Consider a case in which your project uses two dependences, <code>dep1</code> and <code>dep2</code>. <code>dep2</code> in turn also uses <code>dep1</code>, and requires a particular minimum version to function. If you then use <code>dependencyManagement</code> to specify an older version, <code>dep2</code> will be forced to use the older version, and fail. So, you must be careful to check the entire dependency tree to avoid this problem; <code>mvn dependency:tree</code> is helpful.</p></li></ul></section></section><section> -<h4><a name="Aggregation_.28or_Multi-Module.29"></a><a name="Aggregation">Aggregation</a> (or Multi-Module)</h4> +<h3><a name="Aggregation_.28or_Multi-Module.29"></a><a name="Aggregation">Aggregation</a> (or Multi-Module)</h3> <p>A project with modules is known as a multi-module, or aggregator project. Modules are projects that this POM lists, and are executed as a group. A <code>pom</code> packaged project may aggregate the build of a set of projects by listing them as modules, which are relative paths to the directories or the POM files of those projects.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -654,9 +654,9 @@ Display parameters as parsed by Maven (i </project></pre></div> <p>You do not need to consider the inter-module dependencies yourself when listing the modules; i.e. the ordering of the modules given by the POM is not important. Maven will topologically sort the modules such that dependencies are always build before dependent modules.</p> <p>To see aggregation in action, have a look at the <a class="externalLink" href="https://svn.apache.org/viewvc/maven/maven-3/trunk/pom.xml?view=markup";>Maven</a> or <a class="externalLink" href="https://svn.apache.org/viewvc/maven/plugins/trunk/pom.xml?view=markup";>Maven Core Plugins</a> base POM's.</p><section> -<h5><a name="A_final_note_on_Inheritance_v._Aggregation"></a>A final note on <a name="Inheritance_v._Aggregation">Inheritance v. Aggregation</a></h5> +<h4><a name="A_final_note_on_Inheritance_v._Aggregation"></a>A final note on <a name="Inheritance_v._Aggregation">Inheritance v. Aggregation</a></h4> <p>Inheritance and aggregation create a nice dynamic to control builds through a single, high-level POM. You often see projects that are both parents and aggregators. For example, the entire Maven core runs through a single base POM <a class="externalLink" href="https://svn.apache.org/viewvc/maven/maven-3/trunk/pom.xml?view=markup";><code>org.apache.maven:maven</code></a>, so building the Maven project can be executed by a single command: <code>mvn compile</code>. However, an aggregator project and a parent project are both POM projects, they are not one and the same and should not be confused. A POM project may be inherited from - but does not necessarily have - any modules that it aggregates. Conversely, a POM project may aggregate projects that do not inherit from it.</p></section></section></section><section> -<h3><a name="Properties">Properties</a></h3> +<h2><a name="Properties">Properties</a></h2> <p>Properties are the last required piece to understand POM basics. Maven properties are value placeholders, like properties in Ant. Their values are accessible anywhere within a POM by using the notation <code>${X}</code>, where <code>X</code> is the property. Or they can be used by plugins as default values, for example:</p> <div class="source"><pre class="prettyprint linenums"><project> ... @@ -678,9 +678,9 @@ Display parameters as parsed by Maven (i <li><code>settings.x</code>: A dot (.) notated path in the <code>settings.xml</code> will contain the corresponding element's value. For example: <code><settings><offline>false</offline></settings></code> is accessible via <code>${settings.offline}</code>.</li> <li>Java System Properties: All properties accessible via <code>java.lang.System.getProperties()</code> are available as POM properties, such as <code>${java.home}</code>.</li> <li><code>x</code>: Set within a <code><properties /></code> element in the POM. The value of <code><properties><someVar>value</someVar></properties></code> may be used as <code>${someVar}</code>.</li></ol></section></section><section> -<h2><a name="Build_Settings">Build Settings</a></h2> +<h1><a name="Build_Settings">Build Settings</a></h1> <p>Beyond the basics of the POM given above, there are two more elements that must be understood before claiming basic competency of the POM. They are the <code>build</code> element, that handles things like declaring your project's directory structure and managing plugins; and the <code>reporting</code> element, that largely mirrors the build element for reporting purposes.</p><section> -<h3><a name="Build">Build</a></h3> +<h2><a name="Build">Build</a></h2> <p>According to the POM 4.0.0 XSD, the <code>build</code> element is conceptually divided into two parts: there is a <code>BaseBuild</code> type which contains the set of elements common to both <code>build</code> elements (the top-level build element under <code>project</code> and the build element under <code>profiles</code>, covered below); and there is the <code>Build</code> type, which contains the <code>BaseBuild</code> set as well as more elements for the top level definition. Let us begin with an analysis of the common elements between the two.</p> <p><i>Note: These different</i> <code>build</code> <i>elements may be denoted "project build" and "profile build".</i></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" @@ -696,7 +696,7 @@ Display parameters as parsed by Maven (i </profile> </profiles> </project></pre></div><section> -<h4><a name="The_BaseBuild_Element_Set"></a>The <a name="BaseBuild_Element">BaseBuild Element</a> Set</h4> +<h3><a name="The_BaseBuild_Element_Set"></a>The <a name="BaseBuild_Element">BaseBuild Element</a> Set</h3> <p><code>BaseBuild</code> is exactly as it sounds: the base set of elements between the two <code>build</code> elements in the POM.</p> <div> <pre><build> @@ -714,7 +714,7 @@ Display parameters as parsed by Maven (i <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>. <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> -<h5><a name="Resources">Resources</a></h5> +<h4><a name="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> <p>For example, a Plexus project requires a <code>configuration.xml</code> file (which specifies component configurations to the container) to live within the <code>META-INF/plexus</code> directory. Although we could just as easily place this file within <code>src/main/resources/META-INF/plexus</code>, we want instead to give Plexus its own directory of <code>src/main/plexus</code>. In order for the JAR plugin to bundle the resource correctly, you would specify resources similar to the following:</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" @@ -748,7 +748,7 @@ Display parameters as parsed by Maven (i <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> -<h5><a name="Plugins">Plugins</a></h5> +<h4><a name="Plugins">Plugins</a></h4> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <build> @@ -883,7 +883,7 @@ Display parameters as parsed by Maven (i <li><b>phase</b>: This is the phase that the list of goals will execute in. This is a very powerful option, allowing one to bind any goal to any phase in the build lifecycle, altering the default behavior of Maven.</li> <li><b>inherited</b>: Like the <code>inherited</code> element above, setting this to false will suppress Maven from passing this execution onto its children. This element is only meaningful to parent POMs.</li> <li><b>configuration</b>: Same as above, but confines the configuration to this specific list of goals, rather than all goals under the plugin.</li></ul></li></ul></section><section> -<h5><a name="Plugin_Management">Plugin Management</a></h5> +<h4><a name="Plugin_Management">Plugin Management</a></h4> <ul> <li><b>pluginManagement</b>: is an element that is seen along side plugins. Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build, it is intended to configure project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children or in the current POM. The children have every right to override <code>pluginManagement</code> definitions.</li></ul> <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" @@ -930,9 +930,9 @@ Display parameters as parsed by Maven (i ... </build> </project></pre></div></section></section><section> -<h4><a name="The_Build_Element_Set"></a>The <a name="Build_Element">Build Element</a> Set</h4> +<h3><a name="The_Build_Element_Set"></a>The <a name="Build_Element">Build Element</a> Set</h3> <p>The <code>Build</code> type in the XSD denotes those elements that are available only for the "project build". Despite the number of extra elements (six), there are really only two groups of elements that project build contains that are missing from the profile build: directories and extensions.</p><section> -<h5><a name="Directories">Directories</a></h5> +<h4><a name="Directories">Directories</a></h4> <p>The set of directory elements live in the parent build element, which set various directory structures for the POM as a whole. Since they do not exist in profile builds, these cannot be altered by profiles.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -947,7 +947,7 @@ Display parameters as parsed by Maven (i </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> -<h5><a name="Extensions">Extensions</a></h5> +<h4><a name="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="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"> @@ -964,7 +964,7 @@ Display parameters as parsed by Maven (i ... </build> </project></pre></div></section></section></section><section> -<h3><a name="Reporting">Reporting</a></h3> +<h2><a name="Reporting">Reporting</a></h2> <p>Reporting contains the elements that correspond specifically for the <code>site</code> generation phase. Certain Maven plugins can generate reports defined and configured under the reporting element, for example: generating Javadoc reports. Much like the build element's ability to configure plugins, reporting commands the same ability. The glaring difference is that rather than fine-grained control of plug-in goals within the executions block, reporting configures goals within <code>reportSet</code> elements. And the subtler difference is that a plugin <code>configuration</code> under the <code>reporting</code> element works as <code>build</code> plugin <code>configuration</code>, although the opposite is not true (a <code>build</code> plugin <code>configuration</code> does not affect a <code>reporting</code> plugin).</p> <p>Possibly the only item under the <code>reporting</code> element that would not be familiar to someone who understood the <code>build</code> element is the Boolean <code>excludeDefaults</code> element. This element signifies to the site generator to exclude reports normally generated by default. When a site is generated via the <code>site</code> build cycle, a <i>Project Info</i> section is placed in the left-hand menu, chock full of reports, such as the <b>Project Team</b> report or <b>Dependencies</b> list report. These report goals are generated by <code>maven-project-info-reports-plugin</code>. Being a plugin like any other, it may also be suppressed in the following, more verbose, way, which effectively turns off project-info reports.</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" @@ -985,7 +985,7 @@ Display parameters as parsed by Maven (i ... </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> -<h4><a name="Report_Sets">Report Sets</a></h4> +<h3><a name="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> <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" @@ -1015,14 +1015,14 @@ Display parameters as parsed by Maven (i ... </project></pre></div> <p>Between build <code>executions</code> and reporting <code>reportSets</code>, it should be clear now as to why they exist. In the simplest sense, they drill down in configuration. The POM must have a way not only to configure plugins, but must also configure the goals of those plugins. That is where these elements come in, giving the POM ultimate granularity in control of its build destiny.</p></section></section></section><section> -<h2><a name="More_Project_Information">More Project Information</a></h2> +<h1><a name="More_Project_Information">More Project Information</a></h1> <p>Several elements do not affect the build, but rather document the project for the convenience of developers. Many of these elements are used to fill in project details when generating the project's web site. However, like all POM declarations, plugins can use them for anything. The following are the simplest elements:</p> <ul> <li><b>name</b>: Projects tend to have conversational names, beyond the <code>artifactId</code>. The Sun engineers did not refer to their project as "java-1.5", but rather just called it "Tiger". Here is where to set that value.</li> <li><b>description</b>: A short, human readable description of the project. Although this should not replace formal documentation, a quick comment to any readers of the POM is always helpful.</li> <li><b>url</b>: The project's home page.</li> <li><b>inceptionYear</b>: The year the project was first created. </li></ul><section> -<h3><a name="Licenses">Licenses</a></h3> +<h2><a name="Licenses">Licenses</a></h2> <div class="source"><pre class="prettyprint linenums"><licenses> <license> <name>Apache License, Version 2.0</name> @@ -1035,7 +1035,7 @@ Display parameters as parsed by Maven (i <ul> <li><b>name</b>, <b>url</b> and <b>comments</b>: are self explanatory, and have been encountered before in other contexts. Using an <a class="externalLink" href="https://spdx.org/licenses/";>SPDX identifier</a> as the license <b>name</b> is recommended. The fourth license element is:</li> <li><b>distribution</b>: This describes how the project may be legally distributed. The two stated methods are repo (they may be downloaded from a Maven repository) or manual (they must be manually installed).</li></ul></section><section> -<h3><a name="Organization">Organization</a></h3> +<h2><a name="Organization">Organization</a></h2> <p>Most projects are run by some sort of organization (business, private group, etc.). Here is where the most basic information is set.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1045,7 +1045,7 @@ Display parameters as parsed by Maven (i <url>http://mojo.codehaus.org</url> </organization> </project></pre></div></section><section> -<h3><a name="Developers">Developers</a></h3> +<h2><a name="Developers">Developers</a></h2> <p>All projects consist of files that were created, at some time, by a person. Like the other systems that surround a project, so to do the people involved with a project have a stake in the project. Developers are presumably members of the project's core development. Note that, although an organization may have many developers (programmers) as members, it is not good form to list them all as developers, but only those who are immediately responsible for the code. A good rule of thumb is, if the person should not be contacted about the project, they do not need to be listed here.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1076,7 +1076,7 @@ Display parameters as parsed by Maven (i <li><b>roles</b>: A <code>role</code> should specify the standard actions that the person is responsible for. Like a single person can wear many hats, a single person can take on multiple <code>roles</code>.</li> <li><b>timezone</b>: A valid time zone ID like <code>America/New_York</code> or <code>Europe/Berlin</code>, or a numerical offset in hours (and fraction) from UTC where the developer lives, e.g., <code>-5</code> or <code>+1</code>. Time zone IDs are highly preferred because they are not affected by DST and time zone shifts. Refer to the <a class="externalLink" href="https://www.iana.org/time-zones";>IANA</a> for the official time zone database and a listing in <a class="externalLink" href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones";>Wikipedia</a>.</li> <li><b>properties</b>: This element is where any other properties about the person goes. For example, a link to a personal image or an instant messenger handle. Different plugins may use these properties, or they may simply be for other developers who read the POM.</li></ul></section><section> -<h3><a name="Contributors">Contributors</a></h3> +<h2><a name="Contributors">Contributors</a></h2> <p>Contributors are like developers yet play an ancillary role in a project's lifecycle. Perhaps the contributor sent in a bug fix, or added some important documentation. A healthy open source project will likely have more contributors than developers.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1100,8 +1100,8 @@ Display parameters as parsed by Maven (i ... </project></pre></div> <p>Contributors contain the same set of elements than developers sans the <code>id</code> element.</p></section></section><section> -<h2><a name="Environment_Settings">Environment Settings</a></h2><section> -<h3><a name="Issue_Management">Issue Management</a></h3> +<h1><a name="Environment_Settings">Environment Settings</a></h1><section> +<h2><a name="Issue_Management">Issue Management</a></h2> <p>This defines the defect tracking system (<i>Bugzilla</i>, <i>TestTrack</i>, <i>ClearQuest</i>, etc) used. Although there is nothing stopping a plugin from using this information for something, it's primarily used for generating project documentation.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1112,7 +1112,7 @@ Display parameters as parsed by Maven (i </issueManagement> ... </project></pre></div></section><section> -<h3><a name="Continuous_Integration_Management">Continuous Integration Management</a></h3> +<h2><a name="Continuous_Integration_Management">Continuous Integration Management</a></h2> <p>Continuous integration build systems based upon triggers or timings (such as, hourly or daily) have grown in favor over manual builds in the past few years. As build systems have become more standardized, so have the systems that run the trigger those builds. Although the majority of the configuration is up to the specific program used (Continuum, Cruise Control, etc.), there are a few configurations which may take place within the POM. Maven has captured a few of the recurring settings within the set of notifier elements. A notifier is the manner in which people are notified of certain build statuses. In the following example, this POM is setting a notifier of type <code>mail</code> (meaning email), and configuring the email address to use on the specified triggers <code>sendOnError</code>, <code>sendOnFailure</code>, and not <code>sendOnSuccess</code> or <code>sendOnWarning</code>.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1133,7 +1133,7 @@ Display parameters as parsed by Maven (i </ciManagement> ... </project></pre></div></section><section> -<h3><a name="Mailing_Lists">Mailing Lists</a></h3> +<h2><a name="Mailing_Lists">Mailing Lists</a></h2> <p>Mailing lists are a great tool for keeping in touch with people about a project. Most mailing lists are for developers and users.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1156,7 +1156,7 @@ Display parameters as parsed by Maven (i <li><b>subscribe</b>, <b>unsubscribe</b>: There elements specify the email addresses which are used for performing the relative actions To subscribe to the user list above, a user would send an email to user-subscribe@127.0.0.1.</li> <li><b>archive</b>: This element specifies the url of the archive of old mailing list emails, if one exists. If there are mirrored archives, they can be specified under otherArchives.</li> <li><b>post</b>: The email address which one would use in order to post to the mailing list. Note that not all mailing lists have the ability to post to (such as a build failure list).</li></ul></section><section> -<h3><a name="SCM">SCM</a></h3> +<h2><a name="SCM">SCM</a></h2> <p>SCM (Software Configuration Management, also called Source Code/Control Management or, succinctly, version control) is an integral part of any healthy project. If your Maven project uses an SCM system (it does, doesn't it?) then here is where you would place that information into the POM.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1178,7 +1178,7 @@ Display parameters as parsed by Maven (i <pre>scm:cvs:pserver:127.0.0.1:/cvs/root:my-project</pre></div></li> <li><b>tag</b>: Specifies the tag that this project lives under. HEAD (meaning, the SCM root) is the default.</li> <li><b>url</b>: A publicly browsable repository. For example, via ViewCVS.</li></ul></section><section> -<h3><a name="Prerequisites">Prerequisites</a></h3> +<h2><a name="Prerequisites">Prerequisites</a></h2> <p>The POM may have certain prerequisites in order to execute correctly. The only element that exists as a prerequisite in POM 4.0.0 is the <code>maven</code> element, which takes a minimum version number.</p> <p>In Maven 3, use <a href="/enforcer/enforcer-rules/requireMavenVersion.html"> Maven Enforcer Plugin's <code>requireMavenVersion</code> rule</a>, or other rules for <b>build-time</b> prerequisites. For packaging <code>maven-plugin</code> this is still used at <b>run-time</b> to make sure that the minimum Maven version for the plugin is met (but only in the pom.xml of the referenced plugin).</p> <p>In Maven 2 those prerequisites were also evaluated at build time: if these are not met, Maven 2 will fail the build before even starting.</p> @@ -1190,7 +1190,7 @@ Display parameters as parsed by Maven (i </prerequisites> ... </project></pre></div></section><section> -<h3><a name="Repositories">Repositories</a></h3> +<h2><a name="Repositories">Repositories</a></h2> <p>Repositories are collections of artifacts which adhere to the Maven repository directory layout. In order to be a Maven repository artifact, a POM file must live within the structure <code>$BASE_REPO/groupId/artifactId/version/artifactId-version.pom</code>. <code>$BASE_REPO</code> can be local (file structure) or remote (base URL); the remaining layout will be the same. Repositories exist as a place to collect and store artifacts. Whenever a project has a dependency upon an artifact, Maven will first attempt to use a local copy of the specified artifact. If that artifact does not exist in the local repository, it will then attempt to download from a remote repository. The repository elements within a POM specify those alternate repositories to search.</p> <p>The repository is one of the most powerful features of the Maven community. By default Maven searches the central repository at <a class="externalLink" href="https://repo.maven.apache.org/maven2/";>https://repo.maven.apache.org/maven2/</a>. Additional repositories can be configured in the pom.xml `repositories` element. </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" @@ -1225,9 +1225,9 @@ Display parameters as parsed by Maven (i <li><b>updatePolicy</b>: This element specifies how often updates should attempt to occur. Maven will compare the local POM's timestamp (stored in a repository's maven-metadata file) to the remote. The choices are: <code>always</code>, <code>daily</code> (default), <code>interval:X</code> (where X is an integer in minutes) or <code>never</code>.</li> <li><b>checksumPolicy</b>: When Maven deploys files to the repository, it also deploys corresponding checksum files. Your options are to <code>ignore</code>, <code>fail</code>, or <code>warn</code> on missing or incorrect checksums.</li> <li><b>layout</b>: In the above description of repositories, it was mentioned that they all follow a common layout. This is mostly correct. The layout introduced with Maven 2 is the default layout for repositories used by Maven both 2 & 3; however, Maven 1.x had a different layout. Use this element to specify which if it is <code>default</code> or <code>legacy</code>.</li></ul></section><section> -<h3><a name="Plugin_Repositories">Plugin Repositories</a></h3> +<h2><a name="Plugin_Repositories">Plugin Repositories</a></h2> <p>Repositories are home to two major types of artifacts. The first are artifacts that are used as dependencies of other artifacts. These are the majority of artifacts that reside within central. The other type of artifact is plugins. Maven plugins are themselves a special type of artifact. Because of this, plugin repositories may be separated from other repositories (although, I have yet to hear a convincing argument for doing so). In any case, the structure of the <code>pluginRepositories</code> element block is similar to the <code>repositories</code> element. The <code>pluginRepository</code> elements each specify a remote location of where Maven can find new plugins.</p></section><section> -<h3><a name="Distribution_Management">Distribution Management</a></h3> +<h2><a name="Distribution_Management">Distribution Management</a></h2> <p>Distribution management acts precisely as it sounds: it manages the distribution of the artifact and supporting files generated throughout the build process. Starting with the last elements first:</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1248,7 +1248,7 @@ Display parameters as parsed by Maven (i <li><b>partner</b>: This artifact has been synchronized with a partner repository.</li> <li><b>deployed</b>: By far the most common status, meaning that this artifact was deployed from a Maven 2 or 3 instance. This is what you get when you manually deploy using the command-line deploy phase.</li> <li><b>verified</b>: This project has been verified, and should be considered finalized.</li></ul></li></ul><section> -<h4><a name="Repository">Repository</a></h4> +<h3><a name="Repository">Repository</a></h3> <p>Whereas the repositories element specifies in the POM the location and manner in which Maven may download remote artifacts for use by the current project, distributionManagement specifies where (and how) this project will get to a remote repository when it is deployed. The repository elements will be used for snapshot distribution if the snapshotRepository is not defined.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1277,7 +1277,7 @@ Display parameters as parsed by Maven (i <li><b>uniqueVersion</b>: The unique version takes a <code>true</code> or <code>false</code> value to denote whether artifacts deployed to this repository should get a uniquely generated version number, or use the version number defined as part of the address.</li> <li><b>url</b>: This is the core of the repository element. It specifies both the location and the transport protocol used to transfer a built artifact (and POM file, and checksum data) to the repository.</li> <li><b>layout</b>: These are the same types and purpose as the layout element defined in the repository element. They are <code>default</code> and <code>legacy</code>.</li></ul></section><section> -<h4><a name="Site_Distribution">Site Distribution</a></h4> +<h3><a name="Site_Distribution">Site Distribution</a></h3> <p>More than distribution to the repositories, <code>distributionManagement</code> is responsible for defining how to deploy the project's site and documentation.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1295,7 +1295,7 @@ Display parameters as parsed by Maven (i </project></pre></div> <ul> <li><b>id</b>, <b>name</b>, <b>url</b>: These elements are similar to their counterparts above in the <code>distributionManagement</code> <code>repository</code> element.</li></ul></section><section> -<h4><a name="Relocation">Relocation</a></h4> +<h3><a name="Relocation">Relocation</a></h3> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0"1 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"> ... @@ -1312,7 +1312,7 @@ Display parameters as parsed by Maven (i ... </project></pre></div> <p>Projects are not static; they are living things (or dying things, as the case may be). A common thing that happens as projects grow, is that they are forced to move to more suitable quarters. For example, when your next wildly successful open source project moves under the Apache umbrella, it would be good to give users a heads-up that the project is being renamed to <code>org.apache:my-project:1.0</code>. Besides specifying the new address, it is also good form to provide a message explaining why.</p></section></section><section> -<h3><a name="Profiles">Profiles</a></h3> +<h2><a name="Profiles">Profiles</a></h2> <p>A new feature of the POM 4.0 is the ability of a project to change settings depending on the environment where it is being built. A <code>profile</code> element contains both an optional activation (a profile trigger) and the set of changes to be made to the POM if that profile has been activated. For example, a project built for a test environment may point to a different database than that of the final deployment. Or dependencies may be pulled from different repositories based upon the JDK version used. The elements of profiles are as follows:</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1332,7 +1332,7 @@ Display parameters as parsed by Maven (i </profile> </profiles> </project></pre></div><section> -<h4><a name="Activation">Activation</a></h4> +<h3><a name="Activation">Activation</a></h3> <p>Activations are the key of a profile. The power of a profile comes from its ability to modify the basic POM only under certain circumstances. Those circumstances are specified via an <code>activation</code> element.</p> <div class="source"><pre class="prettyprint linenums"><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> @@ -1372,9 +1372,9 @@ Display parameters as parsed by Maven (i <p><i>To see which profile will activate in a certain build, use the</i> <code>maven-help-plugin</code>.</p> <div> <pre>mvn help:active-profiles</pre></div></section><section> -<h4><a name="The_BaseBuild_Element_Set_.28revisited.29"></a><a name="The_BaseBuild_Element_Set">The BaseBuild Element Set</a> <i>(revisited)</i></h4> +<h3><a name="The_BaseBuild_Element_Set_.28revisited.29"></a><a name="The_BaseBuild_Element_Set">The BaseBuild Element Set</a> <i>(revisited)</i></h3> <p>As mentioned above, the reason for the two types of build elements reside in the fact that it does not make sense for a profile to configure build directories or extensions as it does in the top level of the POM. Reguardless of in which environment the project is built, some values will remain constant, such as the directory structure of the source code. <i>If you find your project needing to keep two sets of code for different environments, it may be prudent to investigate refactoring the project into two or more separate projects.</i></p></section></section></section><section> -<h2><a name="Final">Final</a></h2> +<h1><a name="Final">Final</a></h1> <p>The Maven POM is big. However, its size is also a testament to its versatility. The ability to abstract all of the aspects of a project into a single artifact is powerful, to say the least. Gone are the days of dozens of disparate build scripts and scattered documentation concerning each individual project. Along with Maven's other stars that make up the Maven galaxy - a well defined build lifecycle, easy to write and maintain plugins, centralized repositories, system-wide and user-based configurations, as well as the increasing number of tools to make developers' jobs easier to maintain complex projects - the POM is the large, but bright, center.</p><hr /> <p>Aspects of this guide were originally published in the <a class="externalLink" href="http://www.javaworld.com/javaworld/jw-05-2006/jw-0529-maven.html";>Maven 2 Pom Demystified</a>.</p></section> </main> Modified: maven/website/content/pom/index.html ============================================================================== --- maven/website/content/pom/index.html (original) +++ maven/website/content/pom/index.html Sat Aug 20 12:41:42 2022 @@ -2,14 +2,14 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 1.11.1 from content/apt/pom/index.apt.vm at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/pom/index.apt.vm at 2022-08-20 | Rendered using Apache Maven Fluido Skin 1.11.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> - <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" /> + <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" /> <meta name="author" content="Hervé Boutemy Dennis Lundberg Karl Heinz Marbaise" /> @@ -126,7 +126,7 @@ Karl Heinz Marbaise" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Parent_POMs"></a>Parent POMs</h2> +<h1><a name="Parent_POMs"></a>Parent POMs</h1> <p>Common configurations are provided in parent POMs</p> <table border="1" class="table table-striped"> <tr class="a"> Modified: maven/website/content/privacy-policy.html ============================================================================== --- maven/website/content/privacy-policy.html (original) +++ maven/website/content/privacy-policy.html Sat Aug 20 12:41:42 2022 @@ -2,14 +2,14 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 1.11.1 from content/markdown/privacy-policy.md at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/markdown/privacy-policy.md at 2022-08-20 | Rendered using Apache Maven Fluido Skin 1.11.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> - <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" /> + <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" /> <title>Maven – Privacy Policy</title> <link rel="stylesheet" href="./css/apache-maven-fluido-1.11.0.min.css" /> <link rel="stylesheet" href="./css/site.css" /> @@ -121,7 +121,7 @@ </div> </header> <main id="bodyColumn" class="span10" > -<section> +<section><section> <h2><a name="Privacy_Policy"></a>Privacy Policy</h2><!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file @@ -153,8 +153,8 @@ the following:</p> <li>The addresses of pages from where you followed a link to our site.</li> </ol> <p>Part of this information is gathered using a tracking cookie set by the -<a class="externalLink" href="https://www.google.com/analytics/";>Google Analytics</a> service and handled -by Google as described in their <a class="externalLink" href="https://www.google.com/privacy.html";>privacy +<a href="https://www.google.com/analytics/"; class="externalLink">Google Analytics</a> service and handled +by Google as described in their <a href="https://www.google.com/privacy.html"; class="externalLink">privacy policy</a>. See your browser documentation for instructions on how to disable the cookie if you prefer not to share this data with Google.</p> @@ -164,7 +164,7 @@ not track or collect personally identifi gathered data with any personally identifying information from other sources.</p> <p>By using this website, you consent to the collection of this data in the -manner and for the purpose described above.</p></section> +manner and for the purpose described above.</p></section></section> </main> </div> </div> Modified: maven/website/content/project-faq.html ============================================================================== --- maven/website/content/project-faq.html (original) +++ maven/website/content/project-faq.html Sat Aug 20 12:41:42 2022 @@ -2,14 +2,14 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 1.11.1 from content/fml/project-faq.fml at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/fml/project-faq.fml at 2022-08-20 | Rendered using Apache Maven Fluido Skin 1.11.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> - <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" /> + <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" /> <title>Maven – Frequently Asked Questions About Project Metadata</title> <link rel="stylesheet" href="./css/apache-maven-fluido-1.11.0.min.css" /> <link rel="stylesheet" href="./css/site.css" /> @@ -129,7 +129,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Frequently_Asked_Questions_About_Project_Metadata"></a><a name="top">Frequently Asked Questions About Project Metadata</a></h2> +<h1><a name="Frequently_Asked_Questions_About_Project_Metadata"></a><a name="top">Frequently Asked Questions About Project Metadata</a></h1> <ol style="list-style-type: decimal"> <li><a href="#why-care">Why do I care?</a></li> <li><a href="#how-to-improve-metadata">How do I make sure my project's dependency metadata is correct?</a></li> Modified: maven/website/content/project-info.html ============================================================================== --- maven/website/content/project-info.html (original) +++ maven/website/content/project-info.html Sat Aug 20 12:41:42 2022 @@ -2,14 +2,14 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 1.11.1 from org.apache.maven.plugins:maven-site-plugin:3.12.0:CategorySummaryDocumentRenderer at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from org.apache.maven.plugins:maven-site-plugin:4.0.0-M3:CategorySummaryDocumentRenderer at 2022-08-20 | Rendered using Apache Maven Fluido Skin 1.11.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> - <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" /> + <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" /> <title>Maven – Project Information</title> <link rel="stylesheet" href="./css/apache-maven-fluido-1.11.0.min.css" /> <link rel="stylesheet" href="./css/site.css" /> @@ -127,9 +127,9 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Project_Information"></a>Project Information</h2> +<h1><a name="Project_Information"></a>Project Information</h1> <p>This document provides an overview of the various documents and links that are part of this project's general information. All of this content is automatically generated by <a class="externalLink" href="http://maven.apache.org";>Maven</a> on behalf of the project.</p><section> -<h3><a name="Overview"></a>Overview</h3> +<h2><a name="Overview"></a>Overview</h2> <table border="0" class="table table-striped"> <tr class="a"> <th>Document</th> Modified: maven/website/content/project-roles.html ============================================================================== --- maven/website/content/project-roles.html (original) +++ maven/website/content/project-roles.html Sat Aug 20 12:41:42 2022 @@ -2,14 +2,14 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 1.11.1 from content/markdown/project-roles.md at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/markdown/project-roles.md at 2022-08-20 | Rendered using Apache Maven Fluido Skin 1.11.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> - <meta name="generator" content="Apache Maven Doxia Site Renderer 1.11.1" /> + <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0-M3" /> <title>Maven – Apache Maven Project Roles</title> <link rel="stylesheet" href="./css/apache-maven-fluido-1.11.0.min.css" /> <link rel="stylesheet" href="./css/site.css" /> @@ -121,7 +121,8 @@ </div> </header> <main id="bodyColumn" class="span10" > -<h1>Apache Maven Project Roles</h1><!-- +<section> +<h1><a name="Apache_Maven_Project_Roles"></a>Apache Maven Project Roles</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 @@ -141,7 +142,7 @@ under the License. --> <p>The Apache Maven project is not just the software it produces. -The Apache Foundation has a phrase: “Community over code” which +The Apache Foundation has a phrase: Community over code which is about how it is the community that grows around a project that is the most important thing.</p> <p>Everyone reading this is part of the Apache Maven community, @@ -151,9 +152,9 @@ community you are still part of the comm community, we present the following as one such way. Please do not take offence if you disagree with this categorisation. It is important to remember that we are -a <i>community</i> not a <i>clique</i> so you are entitled to disagree +a <em>community</em> not a <em>clique</em> so you are entitled to disagree with others in the community.</p> -<p><i>Note:</i> the right to disagree with other people's opinions +<p><em>Note:</em> the right to disagree with other people's opinions comes with the responsibility not to deliberately cause offence or discord.</p><section> <h2><a name="Informal_roles"></a>Informal roles</h2><section> @@ -167,14 +168,14 @@ lurkers, so if you are a lurker sulking of the Apache Maven project, know that you are a valued member of our community. If you ever feel the need to change your role, we will welcome you with open arms… (and if we don't welcome you -with open arms, please advise the <a class="externalLink" href="mailto:priv...@maven.apache.org";>Project management committee</a> +with open arms, please advise the <a href="mailto:priv...@maven.apache.org"; class="externalLink">Project management committee</a> who are responsible for ensuring that the community is a healthy one)</p></section><section> <h3><a name="Consumers"></a>Consumers</h3> <p>People who use Maven, but do not actively join the community. This does not include people who are: subscribed to one of the Maven mailing lists; active in a Maven user community (e.g. -something like <a class="externalLink" href="https://stackoverflow.com/questions/tagged/maven";>stackoverflow</a>; submitting bug reports; etc.).</p> +something like <a href="https://stackoverflow.com/questions/tagged/maven"; class="externalLink">stackoverflow</a>; submitting bug reports; etc.).</p> <p>Maybe Apache Maven is the perfect product for you and does exactly what you need and want, and you never have a need to ask questions about how to use Maven as it is immediately @@ -188,7 +189,7 @@ let us know:</p> <ul> <li>Submitting bug reports is the best way to let us know about bugs,</li> -<li>Asking questions on the <a class="externalLink" href="mailto:us...@maven.apache.org";>Users Mailing List</a> is the best way +<li>Asking questions on the <a href="mailto:us...@maven.apache.org"; class="externalLink">Users Mailing List</a> is the best way get answers to questions.</li> </ul> <p>As a last resort, other Maven user communities are another route @@ -202,7 +203,7 @@ community.</p></section><section> <ul> <li>Submitted a bug report,</li> -<li>Asked a question on the <a class="externalLink" href="mailto:us...@maven.apache.org";>Maven user list</a>,</li> +<li>Asked a question on the <a href="mailto:us...@maven.apache.org"; class="externalLink">Maven user list</a>,</li> <li>Joined one of the other Maven user communities.</li> </ul> <p>We hope your bug report has received some attention. If it @@ -216,7 +217,7 @@ answers you know? If everybody did that, have an answer. Pay it forward!</p> <p>We hope your experience in one of the other Maven user communities is a positive one, so why not join the canonical -Maven user community and subscribe to the <a class="externalLink" href="mailto:us...@maven.apache.org";>Maven user list</a>?</p></section><section> +Maven user community and subscribe to the <a href="mailto:us...@maven.apache.org"; class="externalLink">Maven user list</a>?</p></section><section> <h3><a name="Contributors"></a>Contributors</h3> <p>People who use Maven, have joined the Maven community and contribute back to the community. This includes people who:</p> @@ -224,7 +225,7 @@ back to the community. This includes peo <li>Submit reports of the results of testing proposed releases of Maven and Maven plugins,</li> -<li>Answer questions on the <a class="externalLink" href="mailto:us...@maven.apache.org";>Maven user list</a> (or even other Maven user communities),</li> +<li>Answer questions on the <a href="mailto:us...@maven.apache.org"; class="externalLink">Maven user list</a> (or even other Maven user communities),</li> <li>Submit patches to resolve reported bugs in Maven or Maven plugins hosted at Apache,</li> <li>Help curate bug reports by identifying duplicate reports, or related issues.</li> @@ -234,10 +235,10 @@ related issues.</li> community. If we like what we see, we may even ask you to consider taking a formal role in our project.</p></section></section><section> <h2><a name="Formal_roles"></a>Formal roles</h2><section> -<h3><a name="Committers"></a><a class="externalLink" href="https://www.apache.org/foundation/how-it-works.html#committers";>Committers</a></h3> +<h3><a name="Committers"></a><a href="https://www.apache.org/foundation/how-it-works.html#committers"; class="externalLink">Committers</a></h3> <p>These are those people who have been given write access to the Apache Maven code repository and have a signed -<a class="externalLink" href="https://www.apache.org/licenses/#clas";>Contributor License Agreement (CLA)</a> on file with the ASF.</p> +<a href="https://www.apache.org/licenses/#clas"; class="externalLink">Contributor License Agreement (CLA)</a> on file with the ASF.</p> <p>The Apache Maven project uses a Commit then Review policy and has <a href="/developers/index.html#Developers_Conventions">a number of conventions</a> which should be followed.</p> <p>Committers are responsible for ensuring that every file they @@ -252,9 +253,9 @@ the responsibilities of a committer, the emeritus.</p> <p>At any time, an emeritus committer for the Apache Maven project may decide that they want to become an active committer again -by informing the <a class="externalLink" href="mailto:priv...@maven.apache.org";>project management committee</a>. The current +by informing the <a href="mailto:priv...@maven.apache.org"; class="externalLink">project management committee</a>. The current policy is that committer role reinstatement is automatic.</p></section><section> -<h3><a name="Project_Management_Committee"></a><a class="externalLink" href="https://www.apache.org/foundation/how-it-works.html#pmc-members";>Project Management Committee</a></h3> +<h3><a name="Project_Management_Committee"></a><a href="https://www.apache.org/foundation/how-it-works.html#pmc-members"; class="externalLink">Project Management Committee</a></h3> <p>The Project Management Committee as a whole is the entity that controls the project. Membership of the Project Management Committee is decided by the board of the Apache Software Foundation, based on @@ -319,7 +320,7 @@ thus no requirement that other Apache pr are thus:</p> <ul> -<li>A <a class="externalLink" href="https://www.apache.org/legal/3party.html";>compatible license</a>, i.e. <a class="externalLink" href="https://www.apache.org/legal/3party.html#category-a";>Category A</a> or <a class="externalLink" href="https://www.apache.org/legal/3party.html#category-b";>Category B</a></li> +<li>A <a href="https://www.apache.org/legal/3party.html"; class="externalLink">compatible license</a>, i.e. <a href="https://www.apache.org/legal/3party.html#category-a"; class="externalLink">Category A</a> or <a href="https://www.apache.org/legal/3party.html#category-b"; class="externalLink">Category B</a></li> <li>A good technical fit</li> <li>A strong preference on behalf of the portion of the community that will be doing the integration.</li> @@ -373,7 +374,7 @@ of the PMC and committers such that when bring the changes in their fork back to the Apache Maven project their contribution may end up being rejected on the basis of the review of a large set of changes being too difficult/time-consuming.</p></section></section><section> -<h3><a name="Project_Management_Chair"></a><a class="externalLink" href="https://www.apache.org/foundation/how-it-works.html#pmc-chair";>Project Management Chair</a></h3> +<h3><a name="Project_Management_Chair"></a><a href="https://www.apache.org/foundation/how-it-works.html#pmc-chair"; class="externalLink">Project Management Chair</a></h3> <p>For various legal reasons, there are certain things that the Apache Software Foundation can only delegate to an officer of the foundation.</p> <p>The Project Management Committee is responsible for nominating @@ -384,12 +385,12 @@ the project management committee. They d additional gravitas in the project, it is the Project Management Committee as a whole that is responsible for the direction of the project.</p> <p>If things break down and there is no consensus and there is no clear -ability to reach any conclusion <i>and</i> it is in the interest of the +ability to reach any conclusion <em>and</em> it is in the interest of the foundation because damage is done and the board expects the chair to act as an officer of the foundation and clean things up, then the chair can act as an ultimate decision maker, however, by this point the board of the foundation must already be well aware of the situation and -should be actively monitoring the chair.</p></section></section> +should be actively monitoring the chair.</p></section></section></section> </main> </div> </div>
