Modified: maven/website/content/guides/mini/guide-default-execution-ids.html ============================================================================== --- maven/website/content/guides/mini/guide-default-execution-ids.html (original) +++ maven/website/content/guides/mini/guide-default-execution-ids.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/guides/mini/guide-default-execution-ids.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-default-execution-ids.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="John Casey" /> <meta name="date" content="2009-06-10" /> <title>Maven – Guide to Configuring Default Mojo Executions</title> @@ -142,7 +142,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_to_Configuring_Default_Mojo_Executions"></a>Guide to Configuring Default Mojo Executions</h2> +<h1><a name="Guide_to_Configuring_Default_Mojo_Executions"></a>Guide to Configuring Default Mojo Executions</h1> <p>In most cases where you need to configure a plugin, there are two options that work well: plugin-level configuration and execution-level configuration. Plugin-level configuration is the most common method for configuring plugins that will be used from the command line, are defined as part of the default lifecycle, or that use a common configuration across all invocations. In fact, for direct invocation from the command line, plugin-level configuration has been the <i>only</i> option historically.</p> <p>On the other hand, in cases where a more advanced build process requires the execution of mojos - sometimes the same mojos, sometimes different ones - from a single plugin that use different configurations, the execution-level configuration is most commonly used. These cases normally involve plugins that are introduced as part of the standard build process, but which aren't present in the default lifecycle mapping for that particular packaging. In these cases, common settings shared between executions are still normally specified in the plugin-level configuration.</p> <p>However, these two options leave out a few important configuration use cases: </p> @@ -150,9 +150,9 @@ <li>Mojos run from the command line <i>and</i> during the build, when the CLI-driven invocation requires its own configuration.</li> <li>Mojo executions that are bound to the lifecycle as part of the default mapping for a particular packaging, especially in cases where the same mojos need to be added to a second execution with different configuration.</li> <li>Groups of mojos from the same plugin that are bound to the lifecycle as part of the default mapping for a particular packaging, but require separate configurations.</li></ul><section> -<h3><a name="Default_executionIds_for_Implied_Executions"></a>Default <code>executionId</code>s for Implied Executions</h3> +<h2><a name="Default_executionIds_for_Implied_Executions"></a>Default <code>executionId</code>s for Implied Executions</h2> <p>When you consider the fact that the aforementioned configuration use cases are for mojos that are not explicitly mentioned in the POM, it's reasonable to refer to them as implied executions. But if they're implied, how can Maven allow users to provide configuration for them? The solution we've implemented is rather simple and low-tech, but should be more than adequate to handle even advanced use cases. Starting in Maven 2.2.0, each mojo invoked directly from the command line will have an execution Id of <code>default-cli</code> assigned to it, which will allow the configuration of that execution from the POM by using this default execution Id. Likewise, each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of <code>default-<goalName></code> assigned to it, to allow configuration of each default mojo execution independently.</p><section> -<h4><a name="Example:_Command-line_variant_invocation_of_the_assembly_plugin"></a>Example: Command-line variant invocation of the assembly plugin</h4> +<h3><a name="Example:_Command-line_variant_invocation_of_the_assembly_plugin"></a>Example: Command-line variant invocation of the assembly plugin</h3> <p>Consider the case where the user wants to execute the <code>assembly:assembly</code> mojo directly on the command line, but already has a configuration for the <code>assembly:single</code> mojo that runs during the main build lifecycle. Since these configurations require different options, the user cannot use the plugin-level configuration section to specify common elements.</p> <p>In this case, the assembly-plugin configuration might look like this:</p> <div class="source"><pre class="prettyprint linenums"><plugin> @@ -187,7 +187,7 @@ </plugin></pre></div> <p>In the above example, you can see several interesting things. First, the main build process will invoke the <code>assembly:single</code> mojo during the <code>package</code> phase of the build, and produce both binary and source distribution artifacts using custom assembly descriptors included with the project. Second, all invocations of the assembly plugin should use a <code>tarLongFileMode</code> strategy of <code>gnu</code>. Finally, when the assembly plugin is invoked from the command line, it will build the standard <code>jar-with-dependencies</code> and <code>project</code> artifacts for the project, and ignore the custom assembly descriptors in <code>src/main/assembly</code>.</p> <p>Now, notice the difference in the way the two execution blocks reference assembly descriptors. One uses custom descriptors via the <code>descriptors</code> section, and the other uses standard descriptors via the <code>descriptorRefs</code> section. These two sections cannot override one another, so it's impossible to setup one section - say, <code>descriptorRefs</code> - in the plugin-level configuration block (to provide CLI access to it, as historical versions of Maven would require), then have the <code>build-distros</code> invocation override it with the custom descriptors specified in the <code>descriptors</code> section.</p></section><section> -<h4><a name="Example:_Configuring_compile_to_run_twice"></a>Example: Configuring <code>compile</code> to run twice</h4> +<h3><a name="Example:_Configuring_compile_to_run_twice"></a>Example: Configuring <code>compile</code> to run twice</h3> <p>In this scenario, the user wants to run the <code>compiler:compile</code> mojo twice for his <code>jar</code> packaging project. The main reason for this is to provide an entry point into the application that will warn the user if he's using a Java version older than 1.5, then exit gracefully. Without such an entry point, the user would be confronted with a stacktrace in the event he tried to run this application with a 1.4 or older JRE.</p> <p>Therefore, the user needs to compile the bulk of his application to target the 1.5 Java specification, then compile the rest (the entry point) to target an older specification...say, 1.3. The first execution will specify the <code>source</code> and <code>target</code> values at <code>1.5</code>, and add an <code>excludes</code> section to avoid compiling the entry point for the application. The second pass will then re-specify <code>source</code> and <code>target</code> to <code>1.3</code>, and basically invert the original <code>excludes</code> section to be an <code>includes</code> section, so as to compile <i>only</i> the entry point class.</p> <p>The resulting configuration might look something like this:</p> @@ -227,7 +227,7 @@ <li>The default <code>source</code> and <code>target</code> compatibility levels are for Java 1.5. This means that the compiler will generate binaries for Java 1.5 from both the main codebase and the test codebase, unless otherwise overridden.</li> <li>The default pass of the <code>compile</code> goal will <i>exclude</i> the <code>**/cli/*</code> path pattern, but will compile everything else in <code>src/main/java</code> to run under Java 1.5.</li> <li>The second pass of the <code>compile</code> mojo - in the execution called <code>build-java14-cli</code> - resets the <code>source</code> and <code>target</code> versions to <code>1.3</code>, and inverts the exclude rule from the first pass. This means the second time around, the compiler will produce 1.4-targeted binaries for the classes matching the <code>**/cli/*</code> path pattern.</li></ul></section><section> -<h4><a name="Example:_Configuring_compile_and_testCompile_mojos_separately"></a>Example: Configuring <code>compile</code> and <code>testCompile</code> mojos separately</h4> +<h3><a name="Example:_Configuring_compile_and_testCompile_mojos_separately"></a>Example: Configuring <code>compile</code> and <code>testCompile</code> mojos separately</h3> <p>Finally, building on our use of the compiler plugin to tease out these different use cases, consider the case where a user wants to target version 1.4 of the Java specification as his runtime platform. However, he still wants the convenience and other advantages to be found in a unit-testing framework like TestNG. This forces the user to configure the <code>compile</code> mojo with one set of <code>source</code> and <code>target</code> values - specifically, <code>1.4</code> - and the <code>testCompile</code> mojo with another (<code>1.5</code>).</p> <p>The resulting compiler-plugin configuration might look something like the following:</p> <div class="source"><pre class="prettyprint linenums"><plugin>
Modified: maven/website/content/guides/mini/guide-deployment-security-settings.html ============================================================================== --- maven/website/content/guides/mini/guide-deployment-security-settings.html (original) +++ maven/website/content/guides/mini/guide-deployment-security-settings.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/guides/mini/guide-deployment-security-settings.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-deployment-security-settings.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="Jason van Zyl" /> <meta name="date" content="2005-10-12" /> <title>Maven – Guide to Deployment and Security Settings</title> @@ -153,7 +153,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Security_and_Deployment_Settings"></a>Security and Deployment Settings</h2> +<h1><a name="Security_and_Deployment_Settings"></a>Security and Deployment Settings</h1> <p>Repositories to deploy to are defined in a project in the <code>distributionManagement</code> section. However, you cannot put your username, password, or other security settings in that project. For that reason, you should add a server definition to your own settings with an id that matches that of the deployment repository in the project.</p> <p>In addition, some repositories may require authorisation to download from, so the corresponding settings can be specified in a server element in the same way.</p> <p>Which settings are required will depend on the type of repository you are deploying to. As of the first release, only SCP deployments and file deployments are supported by default, so only the following SCP configuration is needed:</p> Modified: maven/website/content/guides/mini/guide-encryption.html ============================================================================== --- maven/website/content/guides/mini/guide-encryption.html (original) +++ maven/website/content/guides/mini/guide-encryption.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/guides/mini/guide-encryption.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-encryption.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="Oleg Gusakov Robert Scholte" /> <meta name="date" content="2014-03-23" /> @@ -154,14 +154,14 @@ Robert Scholte" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Password_Encryption">Password Encryption</a></h2> +<h1><a name="Password_Encryption">Password Encryption</a></h1> <ol style="list-style-type: decimal"> <li><a href="#Introduction">Introduction</a></li> <li><a href="#How_to_create_a_master_password">How to create a master password</a></li> <li><a href="#How_to_encrypt_server_passwords">How to encrypt server passwords</a></li> <li><a href="#How_to_keep_the_master_password_on_removable_drive">How to keep the master password on removable drive</a></li> <li><a href="#Tips">Tips</a></li></ol><section> -<h3><a name="Introduction">Introduction</a></h3> +<h2><a name="Introduction">Introduction</a></h2> <p>Maven supports server password encryption. The main use case, addressed by this solution is:</p> <ul> <li>multiple users share the same build machine (server, CI box)</li> @@ -179,7 +179,7 @@ Robert Scholte" /> <li>server entries in the <code>settings.xml</code> have passwords and/or keystore passphrases encrypted <ul> <li>for now - this is done via CLI <b>after</b> master password has been created and stored in appropriate location</li></ul></li></ul></section><section> -<h3><a name="How_to_create_a_master_password">How to create a master password</a></h3> +<h2><a name="How_to_create_a_master_password">How to create a master password</a></h2> <p>Use the following command line:</p> <div class="source"><pre class="prettyprint linenums">mvn --encrypt-master-password <password></pre></div> <p><i>Note:</i> Since Maven 3.2.1 the password argument should no longer be used (see <a href="#Tips">Tips</a> below for more information). Maven will prompt for the password. Earlier versions of Maven will not prompt for a password, so it must be typed on the command-line in plaintext.</p> @@ -191,7 +191,7 @@ Robert Scholte" /> <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master> </settingsSecurity></pre></div> <p>When this is done, you can start encrypting existing server passwords.</p></section><section> -<h3><a name="How_to_encrypt_server_passwords">How to encrypt server passwords</a></h3> +<h2><a name="How_to_encrypt_server_passwords">How to encrypt server passwords</a></h2> <p>You have to use the following command line:</p> <div class="source"><pre class="prettyprint linenums">mvn --encrypt-password <password></pre></div> <p><i>Note:</i>Just like <code>--encrypt-master-password</code> the password argument should no longer be used since Maven 3.2.1 (see <a href="#Tips">Tips below for more information.</a>).</p> @@ -230,7 +230,7 @@ Robert Scholte" /> <div class="source"><pre class="prettyprint linenums">mvn deploy:deploy-file -Durl=https://maven.corp.com/repo \ -DrepositoryId=my.server \ -Dfile=your-artifact-1.0.jar \</pre></div></section><section> -<h3><a name="How_to_keep_the_master_password_on_removable_drive">How to keep the master password on removable drive</a></h3> +<h2><a name="How_to_keep_the_master_password_on_removable_drive">How to keep the master password on removable drive</a></h2> <p>Create the master password exactly as described above, and store it on a removable drive, for instance on OSX, my USB drive mounts as <code>/Volumes/mySecureUsb</code>, so I store</p> <div class="source"><pre class="prettyprint linenums"><settingsSecurity> <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master> @@ -241,8 +241,8 @@ Robert Scholte" /> <relocation>/Volumes/mySecureUsb/secure/settings-security.xml</relocation> </settingsSecurity></pre></div> <p>This assures that encryption only works when the USB drive is mounted by the OS. This addresses a use case where only certain people are authorized to deploy and are issued these devices.</p></section><section> -<h3><a name="Tips">Tips</a></h3><section> -<h4><a name="Escaping_curly-brace_literals_in_your_password_.28Since:_Maven_2.2.0.29"></a>Escaping curly-brace literals in your password <i>(Since: Maven 2.2.0)</i></h4> +<h2><a name="Tips">Tips</a></h2><section> +<h3><a name="Escaping_curly-brace_literals_in_your_password_.28Since:_Maven_2.2.0.29"></a>Escaping curly-brace literals in your password <i>(Since: Maven 2.2.0)</i></h3> <p>At times, you might find that your password (or the encrypted form of it) contains '{' or '}' as a literal value. If you added such a password as-is to your settings.xml file, you would find that Maven does strange things with it. Specifically, Maven treats all the characters preceding the '{' literal, and all the characters after the '}' literal, as comments. Obviously, this is not the behavior you want. What you really need is a way of <b>escaping</b> the curly-brace literals in your password.</p> <p>You can do this with the widely used '\' escape character. If your password looks like this:</p> <div> @@ -250,20 +250,20 @@ Robert Scholte" /> <p>Then, the value you would add to your settings.xml looks like this:</p> <div> <pre>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+\{EF1iFQyJQ=}</pre></div></section><section> -<h4><a name="Password_Security"></a>Password Security</h4> +<h3><a name="Password_Security"></a>Password Security</h3> <p>Editing <code>settings.xml</code> and running the above commands can still leave your password stored locally in plaintext. You may want to check the following locations:</p> <ul> <li>Shell history (e.g. by running <code>history</code>). You may want to clear your history after encrypting the above passwords</li> <li>Editor caches (e.g. <code>~/.viminfo</code>)</li></ul> <p>Also note that the encrypted passwords can be decrypted by someone that has the master password and settings security file. Keep this file secure (or stored separately) if you expect the possibility that the <code>settings.xml</code> file may be retrieved.</p></section><section> -<h4><a name="Password_Escaping_on_different_platforms"></a>Password Escaping on different platforms</h4> +<h3><a name="Password_Escaping_on_different_platforms"></a>Password Escaping on different platforms</h3> <p>On some platforms it might be necessary to quote the password if it contains special characters like <code>%</code>, <code>!</code>, <code>$</code>, etc. For example on Windows you have to be careful about things like the following:</p> <p>The following example will not work on Windows:</p> <div class="source"><pre class="prettyprint linenums">mvn --encrypt-master-password a!$%^b</pre></div> <p>whereas the following will work on Windows:</p> <div class="source"><pre class="prettyprint linenums">mvn --encrypt-master-password "a!$%^b"</pre></div> <p>If you are on a linux/unix platform you should use single quotes for the above master password. Otherwise the master password will not work (caused by the dollar sign and the exclamation mark).</p></section><section> -<h4><a name="Prompting_for_Password"></a>Prompting for Password</h4> +<h3><a name="Prompting_for_Password"></a>Prompting for Password</h3> <p>In Maven before version 3.2.1 you have to give the password on the command line as an argument which means you might need to escape your password. In addition usually the shell stores the full history of commands you have entered, therefore anyone with access to your computer could restore the password from the shell`s history.</p> <p>Starting with Maven 3.2.1, the password is an optional argument. If you omit the password, you will be prompted for it which prevents all the issues mentioned above.</p> <p>We strongly recommend using Maven 3.2.1 and above to prevent problems with escaping special characters and of course security issues related to bash history or environment issues in relationship with the password.</p></section></section></section> Modified: maven/website/content/guides/mini/guide-generating-sources.html ============================================================================== --- maven/website/content/guides/mini/guide-generating-sources.html (original) +++ maven/website/content/guides/mini/guide-generating-sources.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/guides/mini/guide-generating-sources.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-generating-sources.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="Jason van Zyl Karl Heinz Marbaise" /> <meta name="date" content="2005-10-12 @@ -157,7 +157,7 @@ Karl Heinz Marbaise" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_to_generating_sources"></a>Guide to generating sources</h2> +<h1><a name="Guide_to_generating_sources"></a>Guide to generating sources</h1> <p>Let's run though a short example to try and help. To generate sources you must first have a plugin that participates in the <code>generate-sources</code> phase like the <a class="externalLink" href="http://www.antlr.org/api/maven-plugin/latest/";>ANTLR4 Maven Plugin</a>.</p> <p>So this is all fine and dandy, we have a plugin that wants to generate some sources from a Antlr4 grammar but how do we use it. You need to specify that you want to use it in your POM:</p> <div class="source"><pre class="prettyprint linenums"> Modified: maven/website/content/guides/mini/guide-http-settings.html ============================================================================== --- maven/website/content/guides/mini/guide-http-settings.html (original) +++ maven/website/content/guides/mini/guide-http-settings.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/guides/mini/guide-http-settings.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-http-settings.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="John Casey" /> <meta name="date" content="2011-12-12" /> <title>Maven – Guide to Advanced HTTP Wagon Configuration</title> @@ -153,7 +153,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Advanced_Configuration_of_the_HttpClient_HTTP_Wagon"></a>Advanced Configuration of the HttpClient HTTP Wagon</h2> +<h1><a name="Advanced_Configuration_of_the_HttpClient_HTTP_Wagon"></a>Advanced Configuration of the HttpClient HTTP Wagon</h1> <ul> <li><a href="#Advanced_Configuration_of_the_HttpClient_HTTP_Wagon">Advanced Configuration of the HttpClient HTTP Wagon</a> <ul> @@ -178,9 +178,9 @@ <li>http(s) connection pool: default to 20.</li> <li>readTimeout: default to 1,800,000ms (~30 minutes) (see section <code>Read time out</code> below)</li> <li>default Preemptive Authentication only with PUT (GET doesn't use anymore default Preemptive Authentication)</li></ul><section> -<h3><a name="Introduction"></a>Introduction</h3> +<h2><a name="Introduction"></a>Introduction</h2> <p>The HttpClient-based HTTP wagon offers more control over the configuration used to access HTTP-based Maven repositories. For starters, you have fine-grained control over what HTTP headers are used when resolving artifacts. In addition, you can also configure a wide range of parameters to control the behavior of HttpClient itself. Best of all, you have the ability to control these headers and parameters for all requests, or individual request types (GET, HEAD, and PUT).</p></section><section> -<h3><a name="The_Basics"></a>The Basics</h3> +<h2><a name="The_Basics"></a>The Basics</h2> <p>Without any special configuration, Maven's HTTP wagon uses some default HTTP headers and client parameters when managing artifacts. The default headers are:</p> <div class="source"><pre class="prettyprint linenums">Cache-control: no-cache Cache-store: no-store @@ -206,7 +206,7 @@ problems with HTTP servers and proxies t <p>Without this setting, PUT requests that require authentication transfer their entire payload to the server before that server issues an authentication challenge. In order to complete the PUT request, the client must then re-send the payload with the proper credentials specified in the HTTP headers. This results in twice the bandwidth usage, and twice the time to transfer each artifact.</p> <p>Another option to avoid this double transfer is what's known as preemptive authentication, which involves sending the authentication headers along with the original PUT request. However, there are a few potential issues with this approach. For one thing, in the event you have an unused <code><server></code> entry that specifies an invalid username/password combination, some servers may respond with a <code>401 Unauthorized</code> even if the server doesn't actually require any authentication for the request. In addition, blindly sending authentication credentials with every request regardless of whether the server has made a challenge can result in a security hole, since the server may not make provisions to secure credentials for paths that don't require authentication.</p> <p>We'll discuss preemptive authentication in another example, below.</p></section><section> -<h3><a name="Configuring_GET.2C_HEAD.2C_PUT.2C_or_All_of_the_Above"></a>Configuring GET, HEAD, PUT, or All of the Above</h3> +<h2><a name="Configuring_GET.2C_HEAD.2C_PUT.2C_or_All_of_the_Above"></a>Configuring GET, HEAD, PUT, or All of the Above</h2> <p>In all of the examples below, it's important to understand that you can configure the HTTP settings for all requests made to a given server, or for only one method. To configure all methods for a server, use the following section of the <code>settings.xml</code> file:</p> <div class="source"><pre class="prettyprint linenums"><settings> [...] @@ -240,7 +240,7 @@ problems with HTTP servers and proxies t </servers> </settings></pre></div> <p>For clarity, the other two sections are <code><get></code> for GET requests, and <code><head></code> for HEAD requests. I know that's going to be hard to remember...</p></section><section> -<h3><a name="Taking_Control_of_Your_HTTP_Headers"></a>Taking Control of Your HTTP Headers</h3> +<h2><a name="Taking_Control_of_Your_HTTP_Headers"></a>Taking Control of Your HTTP Headers</h2> <p>As you may have noticed above, the default HTTP headers do have the potential to cause problems. For instance, some websites set the encoding for downloading GZipped files as <code>gzip</code>, in spite of the fact that the HTTP request itself isn't being sent using GZip compression. If the client is using the <code>Accept-Encoding: gzip</code> header, this can result in the client itself decompressing the GZipped file <i>during the transfer</i> and writing the decompressed file to the local disk with the original filename. This can be misleading to say the least, and can use up an inordinate amount of disk space on the local computer.</p> <p>To turn off this default behavior, simply disable the default headers. Then, respecify the other headers that you are still interested in, like this:</p> <div class="source"><pre class="prettyprint linenums"><settings> @@ -282,9 +282,9 @@ problems with HTTP servers and proxies t </servers> [...] </settings></pre></div></section><section> -<h3><a name="Fine-Tuning_HttpClient_Parameters"></a>Fine-Tuning HttpClient Parameters</h3> +<h2><a name="Fine-Tuning_HttpClient_Parameters"></a>Fine-Tuning HttpClient Parameters</h2> <p>Going beyond the power of HTTP request parameters, HttpClient provides a host of other configuration options. In most cases, you won't need to customize these. But in case you do, Maven provides access to specify your own fine-grained configuration for HttpClient. Again, you can specify these parameter customizations per-method (HEAD, GET, or PUT), or for all methods of interacting with a given server. For a complete list of supported parameters, see the link[2] in Resources section below.</p><section> -<h4><a name="Non-String_Parameter_Values"></a>Non-String Parameter Values</h4> +<h3><a name="Non-String_Parameter_Values"></a>Non-String Parameter Values</h3> <p>Many of the configuration parameters for HttpClient have simple string values; however, there are important exceptions to this. In some cases, you may need to specify boolean, integer, or long values. In others, you may even need to specify a collection of string values. You can specify these using a simple formatting syntax, as follows:</p> <ol style="list-style-type: decimal"> <li><b>booleans:</b> <code>%b,<value></code></li> @@ -298,7 +298,7 @@ problems with HTTP servers and proxies t <value3>, ...</pre></div></li></ol> <p>As you may have noticed, this syntax is similar to the format-and-data strategy used by functions like <code>sprintf()</code> in many languages. The syntax has been chosen with this similarity in mind, to make it a little more intuitive to use.</p></section><section> -<h4><a name="Example:_Using_Preemptive_Authentication"></a>Example: Using Preemptive Authentication</h4> +<h3><a name="Example:_Using_Preemptive_Authentication"></a>Example: Using Preemptive Authentication</h3> <p>Using the above syntax, you can configure preemptive authentication for PUT requests using the boolean HttpClient parameter <code>http.authentication.preemptive</code>, like this:</p> <div class="source"><pre class="prettyprint linenums"><settings> <servers> @@ -334,9 +334,9 @@ problems with HTTP servers and proxies t </server> </servers> </settings></pre></div></section><section> -<h4><a name="Example:_Lifting_auth_scope_restriction_for_external_authentication_systems"></a>Example: Lifting auth scope restriction for external authentication systems</h4> +<h3><a name="Example:_Lifting_auth_scope_restriction_for_external_authentication_systems"></a>Example: Lifting auth scope restriction for external authentication systems</h3> <p>Maven Wagon by default limits supplied credentials to the host:port combination scope, ignoring any other target servers. When the target server delegates authentication to an external system, you need to deliberately lift that scope limitation. Configure your server element to pass authentication to all target servers which challenge the client. +---+ <i>settings</i> <i>servers</i> <i>server</i> <i>id</i>my-server<i>/id</i> <i>configuration</i> <i>basicAuthScope</i> <i>host</i>ANY<i>/host</i> <i>port</i>ANY<i>/port</i> <i>!-- or even 443 to force the use of TLS --</i> <i>/basicAuthScope</i> <i>httpConfiguration</i> <i>all</i> <i>params</i> <i>property</i> <i>name</i>http.protocol.cookie-policy<i>/name</i> <i>value</i>standard<i>/value</i> <i>/property</i> <i>/params</i> <i>/all</i> <i>/httpConfiguration</i> <i>/configuration</i> <i>/server</i> <i>/servers</i> <i>/settings</i> +---+</p></section><section> -<h4><a name="Ignoring_Cookies"></a>Ignoring Cookies</h4> +<h3><a name="Ignoring_Cookies"></a>Ignoring Cookies</h3> <p>Like the example above, telling the HttpClient to ignore cookies for all methods of request is a simple matter of configuring the <code>http.protocol.cookie-policy</code> parameter (it uses a regular string value, so no special syntax is required):</p> <div class="source"><pre class="prettyprint linenums"><settings> <servers> @@ -358,9 +358,9 @@ problems with HTTP servers and proxies t </servers> </settings></pre></div> <p>The configuration above can be useful in cases where the repository is using cookies - like the session cookies that are often mistakenly turned on or left on in appservers - alongside HTTP redirection. In these cases, it becomes far more likely that the cookie issued by the appserver uses a <code>Path</code> that is inconsistent with the one used by the client to access the server. If you have this problem, and know that you don't need to use this session cookie, you can ignore cookies from this server with the above configuration.</p></section></section><section> -<h3><a name="Support_for_General-Wagon_Configuration_Standards"></a>Support for General-Wagon Configuration Standards</h3> +<h2><a name="Support_for_General-Wagon_Configuration_Standards"></a>Support for General-Wagon Configuration Standards</h2> <p>It should be noted that configuration options previously available in the HttpClient-driven HTTP wagon are still supported in addition to this new, fine-grained approach. These include the configuration of HTTP headers and connection timeouts. Let's examine each of these briefly:</p><section> -<h4><a name="HTTP_Headers"></a>HTTP Headers</h4> +<h3><a name="HTTP_Headers"></a>HTTP Headers</h3> <p>In all HTTP Wagon implementations, you can add your own HTTP headers like this:</p> <div class="source"><pre class="prettyprint linenums"><settings> <servers> @@ -378,7 +378,7 @@ problems with HTTP servers and proxies t </servers> </settings></pre></div> <p>It's important to understand that the above approach doesn't allow you to turn off all of the default HTTP headers; nor does it allow you to specify headers on a per-method basis. However, this configuration remains available in both the lightweight and httpclient-based Wagon implementations.</p></section><section> -<h4><a name="Connection_Timeouts"></a>Connection Timeouts</h4> +<h3><a name="Connection_Timeouts"></a>Connection Timeouts</h3> <p>All wagon implementations that extend the <code>AbstractWagon</code> class, including those for SCP, HTTP, FTP, and more, allow the configuration of a connection timeout, to allow the user to tell Maven how long to wait before giving up on a connection that has not responded. This option is preserved in the HttpClient-based wagon, but this wagon also provides a fine-grained alternative configuration that can allow you to specify timeouts per-method for a given server. The old configuration option - which is still supported - looks like this:</p> <div class="source"><pre class="prettyprint linenums"><settings> <servers> @@ -406,7 +406,7 @@ problems with HTTP servers and proxies t </servers> </settings></pre></div> <p>If all you need is a per-server timeout configuration, you still have the option to use the old <code><timeout></code> parameter. If you need to separate timeout preferences according to HTTP method, you can use one more like that specified directly above.</p></section><section> -<h4><a name="Read_time_out"></a>Read time out</h4> +<h3><a name="Read_time_out"></a>Read time out</h3> <p>With Wagon 2.0 and Apache Maven 3.0.4, a default timeout of 30 minutes comes by default. If you want to change this value, you can add the following setup in your settings:</p> <div class="source"><pre class="prettyprint linenums"><settings> <servers> @@ -422,7 +422,7 @@ problems with HTTP servers and proxies t </server> </servers> </settings></pre></div></section></section><section> -<h3><a name="Resources"></a>Resources</h3> +<h2><a name="Resources"></a>Resources</h2> <ol style="list-style-type: decimal"> <li><a class="externalLink" href="https://hc.apache.org/httpcomponents-client-4.5.x/";>HttpClient website</a></li> <li><a class="externalLink" href="https://hc.apache.org/httpclient-3.x/preference-api.html";>HttpClient preference architecture and configuration guide</a></li> Modified: maven/website/content/guides/mini/guide-large-scale-centralized-deployments.html ============================================================================== --- maven/website/content/guides/mini/guide-large-scale-centralized-deployments.html (original) +++ maven/website/content/guides/mini/guide-large-scale-centralized-deployments.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/guides/mini/guide-large-scale-centralized-deployments.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-large-scale-centralized-deployments.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="Phil Clay" /> <meta name="date" content="2021-01-01" /> <title>Maven – Guide to Large Scale Centralized Deployments</title> @@ -153,7 +153,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_to_Large_Scale_Centralized_Deployments"></a>Guide to Large Scale Centralized Deployments</h2> +<h1><a name="Guide_to_Large_Scale_Centralized_Deployments"></a>Guide to Large Scale Centralized Deployments</h1> <p>This guide covers a simple optimized approach to using a <a href="../../repository-management.html">repository manager</a> in a large organization with hundreds/thousands of Maven projects.</p> <p>The pillars of this approach are:</p> <ol style="list-style-type: decimal"> @@ -163,7 +163,7 @@ <li>Maven clients should upload proprietary artifacts to the repository manager.</li></ul></li> <li>Configure the location to download/upload artifacts in Maven <code>settings.xml</code> files, rather than in <code>pom.xml</code> files.</li> <li>Centrally manage the <code>settings.xml</code> files, and distribute them via automation.</li></ol><section> -<h3><a name="Repository_Manager_Layout">Repository Manager Layout</a></h3> +<h2><a name="Repository_Manager_Layout">Repository Manager Layout</a></h2> <p>Repository managers generally have at least three types of repositories:</p> <dl> <dt>hosted</dt> @@ -183,7 +183,7 @@ <ul> <li><a href="#Managing_Downloads_from_the_Repository_Manager">Download</a> artifacts from the virtual repository.</li> <li><a href="#Managing_Uploads_to_the_Repository_Manager">Upload</a> artifacts to one of the hosted repositories.</li></ul></section><section> -<h3><a name="Managing_Downloads_from_the_Repository_Manager">Managing Downloads from the Repository Manager</a></h3> +<h2><a name="Managing_Downloads_from_the_Repository_Manager">Managing Downloads from the Repository Manager</a></h2> <p>All artifacts used by Maven projects in the organization should be downloaded from the single virtual repository of the repository manager.</p> <p>Maven can be instructed to download artifacts from the repository manager's virtual repository by defining a mirror in the Maven <code>settings.xml</code> file as described in the <a href="./guide-mirror-settings.html">Guide to Mirror Settings</a>.</p> <p>Example: To download artifacts from the corporate repository manager's <code>maven-virtual</code> repository:</p> @@ -200,7 +200,7 @@ </mirrors> ... </settings></pre></div></section><section> -<h3><a name="Managing_Uploads_to_the_Repository_Manager">Managing Uploads to the Repository Manager</a></h3> +<h2><a name="Managing_Uploads_to_the_Repository_Manager">Managing Uploads to the Repository Manager</a></h2> <p>All proprietary artifacts produced by Maven projects in the organization should be uploaded to the repository manager's hosted repositories.</p> <p>The <a href="../../plugins/maven-deploy-plugin">Maven Deploy Plugin</a> can be instructed to upload artifacts to the repository manager's repositories by defining the <code>alt*DeploymentRepository</code> properties in the Maven <code>settings.xml</code> file. When these properties are defined, the Maven Deploy Plugin's <a href="../../plugins/maven-deploy-plugin/deploy-mojo.html">deploy</a> goal uses them instead of the <code><distributionManagement></code> section of <code>pom.xml</code> files to determine where to upload artifacts.</p> <p>Defining the upload destination of artifacts in <code>settings.xml</code> files rather than in the <code><distributionManagement></code> section of <code>pom.xml</code> files allows the destinations to be centrally managed, which simplifies maintenance if the destinations need to change. In other words, rather than changing a huge number of <code>pom.xml</code> files, you just need to change <a href="#Settings_File_Locations">relatively few</a> <code>settings.xml</code> files if/when the distribution locations need to change.</p> @@ -283,7 +283,7 @@ </activeProfiles> ... </settings></pre></div></section><section> -<h3><a name="Settings_File_Locations">Settings File Locations</a></h3> +<h2><a name="Settings_File_Locations">Settings File Locations</a></h2> <p>Maven <code>settings.xml</code> files need to be available wherever Maven builds are performed, typically:</p> <ul> <li>on continuous integration servers, and</li> Modified: maven/website/content/guides/mini/guide-manifest.html ============================================================================== --- maven/website/content/guides/mini/guide-manifest.html (original) +++ maven/website/content/guides/mini/guide-manifest.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/guides/mini/guide-manifest.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-manifest.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="Jason van Zyl Dennis Lundberg" /> <meta name="date" content="2010-08-19" /> @@ -156,7 +156,7 @@ Dennis Lundberg" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_to_Working_with_Manifests"></a>Guide to Working with Manifests</h2> +<h1><a name="Guide_to_Working_with_Manifests"></a>Guide to Working with Manifests</h1> <p>In order to modify the manifest of the archive produced by the packaging plug-ins you need to create a configuration for it. The definitive guide for this is <a href="/shared/maven-archiver/index.html">the site for the Maven Archiver shared component</a>. This component is used by all our packaging plugins.</p></section> </main> </div> Modified: maven/website/content/guides/mini/guide-maven-classloading.html ============================================================================== --- maven/website/content/guides/mini/guide-maven-classloading.html (original) +++ maven/website/content/guides/mini/guide-maven-classloading.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/guides/mini/guide-maven-classloading.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-maven-classloading.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="Jason van Zyl Anders Kristian Andersen" /> <meta name="date" content="2008-12-10" /> @@ -156,24 +156,24 @@ Anders Kristian Andersen" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_to_Maven_Classloading"></a>Guide to Maven Classloading</h2> +<h1><a name="Guide_to_Maven_Classloading"></a>Guide to Maven Classloading</h1> <p>This is a description of the classloader hierarchy in Maven.</p><section> -<h3><a name="Overview"></a>Overview</h3> +<h2><a name="Overview"></a>Overview</h2> <ul> <li>System Classloader</li> <li>Core Classloader</li> <li>Plugin Classloaders</li> <li>Custom Classloaders</li></ul></section><section> -<h3><a name="a1._System_Classloader"></a>1. <a name="System_Classloader">System Classloader</a></h3> +<h2><a name="a1._System_Classloader"></a>1. <a name="System_Classloader">System Classloader</a></h2> <p>Maven uses the <a class="externalLink" href="https://codehaus-plexus.github.io/plexus-classworlds/";>Plexus Classworlds</a> classloading framework with which we create our classloader graph. If you look in your <code>${maven.home}/boot</code> directory you will see a single JAR which is the Classworlds JAR we use to boot the classloader graph. The Classworlds JAR is the only element of the Java <code>CLASSPATH</code> and Classworlds then builds the other classloaders or realms in Classworlds terminology.</p> <p>An Ant script like this will show the contents of the system classloader:</p> <div class="source"><pre class="prettyprint linenums"> <target name="info"> <echo>java.class.path=${java.class.path}</echo> </target></pre></div></section><section> -<h3><a name="a2._Core_Classloader"></a>2. <a name="Core_Classloader">Core Classloader</a></h3> +<h2><a name="a2._Core_Classloader"></a>2. <a name="Core_Classloader">Core Classloader</a></h2> <p>The second classloader down the graph contains the core requirements of Maven. More precisely, the core classloader has the libraries in <code>${maven.home}/lib</code>. In general these are just Maven libraries, e.g. instances of <code><a href="/ref/current/apidocs/org/apache/maven/project/MavenProject.html">MavenProject</a></code> belong to this classloader. We hope to further separate these in the future to just be Maven APIs and have the implementations selected at runtime as required by the system.</p> <p>You can add elements to this classloader by <a href="/ref/current/maven-model/maven.html#class_extension">extensions</a>. These are loaded into the same place as <code>${maven.home}/lib</code> and hence are available to the Maven core and all plugins for the current project and subsequent projects (in future, we plan to remove it from subsequent projects).</p></section><section> -<h3><a name="a3._Plugin_Classloaders"></a>3. <a name="Plugin_Classloaders">Plugin Classloaders</a></h3> +<h2><a name="a3._Plugin_Classloaders"></a>3. <a name="Plugin_Classloaders">Plugin Classloaders</a></h2> <p>After that, each plugin has its own classloader that is a child of Maven's core classloader. The classes in this classloader are taken from the dependencies in the plugin's dependency list.</p> <p>Users can add dependencies to this classloader by adding dependencies to a plugin in the <code><a href="/ref/current/maven-model/maven.html#class_plugin">plugins/plugin</a></code> section of their project <code>pom.xml</code>. Here is a sample of adding <code>ant-nodeps</code> to the plugin classloader of the Antrun Plugin and hereby enabling the use of additional/optional Ant tasks:</p> <div class="source"><pre class="prettyprint linenums"> <plugin> @@ -192,7 +192,7 @@ Anders Kristian Andersen" /> <p>Plugins can inspect their effective runtime class path via the expressions <code>${plugin.artifacts}</code> or <code>${plugin.artifactMap}</code> to have a list or map, respectively, of resolved artifacts injected from the <code><a href="/ref/current/maven-plugin-api/apidocs/org/apache/maven/plugin/descriptor/PluginDescriptor.html">PluginDescriptor</a></code>.</p> <p>Please note that the plugin classloader does neither contain the <a href="/ref/current/maven-model/maven.html#class_dependency">dependencies</a> of the current project nor its build output. Instead, plugins can query the project's compile, runtime and test class path from the <code><a href="/ref/current/apidocs/org/apache/maven/project/MavenProject.html">MavenProject</a></code> in combination with the mojo annotation <code>requiresDependencyResolution</code> from the <a href="/developers/mojo-api-specification.html">Mojo API Specification</a>. For instance, flagging a mojo with <code>@requiresDependencyResolution runtime</code> enables it to query the runtime class path of the current project from which it could create further classloaders.</p> <p>When a build plugin is executed, the thread's context classloader is set to the plugin classloader.</p></section><section> -<h3><a name="a4._Custom_Classloaders"></a>4. <a name="Custom_Classloaders">Custom Classloaders</a></h3> +<h2><a name="a4._Custom_Classloaders"></a>4. <a name="Custom_Classloaders">Custom Classloaders</a></h2> <p>Plugins are free to create further classloaders on their discretion. For example, a plugin might want to create a classloader that combines the plugin class path and the project class path.</p> <p>It is important to understand that the plugin classloader cannot load classes from any of those custom classloaders. Some factory patterns require that. Here you must add the classes to the plugin classloader as shown before.</p></section></section> </main> Modified: maven/website/content/guides/mini/guide-mirror-settings.html ============================================================================== --- maven/website/content/guides/mini/guide-mirror-settings.html (original) +++ maven/website/content/guides/mini/guide-mirror-settings.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/guides/mini/guide-mirror-settings.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-mirror-settings.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="Jason van Zyl Brian Fox Robert Scholte" /> @@ -155,7 +155,7 @@ Robert Scholte" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Using_Mirrors_for_Repositories"></a>Using Mirrors for Repositories</h2> +<h1><a name="Using_Mirrors_for_Repositories"></a>Using Mirrors for Repositories</h1> <p>With <a href="/guides/introduction/introduction-to-repositories.html">Repositories</a> you specify from which locations you want to <i>download</i> certain artifacts, such as dependencies and maven-plugins. Repositories can be <a href="../mini/guide-multiple-repositories.html">declared inside a project</a>, which means that if you have your own custom repositories, those sharing your project easily get the right settings out of the box. However, you may want to use an alternative mirror for a particular repository without changing the project files.</p> <p>Some reasons to use a mirror are:</p> <ul> @@ -179,7 +179,7 @@ Robert Scholte" /> <p>The settings descriptor documentation can be found on the <a href="../../maven-settings/settings.html">Maven Local Settings Model Website</a>.</p> <p><b>Note</b>: The official Maven repository is at <code>https://repo.maven.apache.org/maven2</code> hosted by the Sonatype Company and is distributed worldwide via CDN.</p> <p>A list of known mirrors is available in the <a class="externalLink" href="https://repo.maven.apache.org/maven2/.meta/repository-metadata.xml";>Repository Metadata</a>. These mirrors may not have the same contents and we don't support them in any way.</p></section><section> -<h2><a name="Using_A_Single_Repository"></a>Using A Single Repository</h2> +<h1><a name="Using_A_Single_Repository"></a>Using A Single Repository</h1> <p>You can force Maven to use a single repository by having it mirror all repository requests. The repository must contain all of the desired artifacts, or be able to proxy the requests to other repositories. This setting is most useful when using an internal company repository with a <a href="../../repository-management.html">Maven Repository Manager</a> to proxy external requests.</p> <p>To achieve this, set <code>mirrorOf</code> to <code>*</code>.</p> <p><b>Note:</b> This feature is only available in Maven 2.0.5+.</p> @@ -195,7 +195,7 @@ Robert Scholte" /> </mirrors> ... </settings></pre></div></section><section> -<h2><a name="Advanced_Mirror_Specification"></a>Advanced Mirror Specification</h2> +<h1><a name="Advanced_Mirror_Specification"></a>Advanced Mirror Specification</h1> <p>A single mirror can handle multiple repositories. This is typically used in conjunction with a repository manager, that gives easy centralised configuration of the list of repositories behind.</p> <p>The syntax:</p> <ul> @@ -231,7 +231,7 @@ Robert Scholte" /> </mirrors> ... </settings></pre></div></section><section> -<h2><a name="Creating_Your_Own_Mirror"></a>Creating Your Own Mirror</h2> +<h1><a name="Creating_Your_Own_Mirror"></a>Creating Your Own Mirror</h1> <p>The size of the central repository is <a class="externalLink" href="https://search.maven.org/stats";>increasing steadily</a> To save us bandwidth and you time, mirroring the entire central repository is not allowed. (Doing so will get you automatically banned.) Instead, we suggest you setup a <a href="../../repository-management.html">repository manager</a> as a proxy.</p></section> </main> </div> Modified: maven/website/content/guides/mini/guide-multiple-modules-4.html ============================================================================== --- maven/website/content/guides/mini/guide-multiple-modules-4.html (original) +++ maven/website/content/guides/mini/guide-multiple-modules-4.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/guides/mini/guide-multiple-modules-4.md at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/markdown/guides/mini/guide-multiple-modules-4.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 – Guide to Working with Multiple Modules in Maven 4</title> <link rel="stylesheet" href="../../css/apache-maven-fluido-1.11.0.min.css" /> <link rel="stylesheet" href="../../css/site.css" /> @@ -152,7 +152,7 @@ </div> </header> <main id="bodyColumn" class="span10" > -<section> +<section><section> <h2><a name="Guide_to_Working_with_Multiple_Modules_in_Maven_4"></a>Guide to Working with Multiple Modules in Maven 4</h2><!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file @@ -176,7 +176,7 @@ under the License. <p>As seen in the introduction to the POM, Maven supports project aggregation in addition to project inheritance. This section outlines how Maven processes projects with multiple modules, and how you can work with them more effectively.</p></section><section> <h2><a name="The_Reactor"></a>The Reactor</h2> -<p>The mechanism in Maven that handles multi-module projects is referred to as the <i>reactor</i>. +<p>The mechanism in Maven that handles multi-module projects is referred to as the <em>reactor</em>. This part of the Maven core does the following:</p> <ul> @@ -208,7 +208,7 @@ Using <code>-f</code>, you can point to <li>a build extension declaration on another module in the build</li> <li>the order declared in the <code><modules></code> element (if no other rule applies)</li> </ul> -<p>Note that only “instantiated” references are used - <code>dependencyManagement</code> and <code>pluginManagement</code> elements do not cause a change to the reactor sort order.</p></section><section> +<p>Note that only instantiated references are used - <code>dependencyManagement</code> and <code>pluginManagement</code> elements do not cause a change to the reactor sort order.</p></section><section> <h3><a name="Selecting_Modules"></a>Selecting Modules</h3> <p>By default, Maven builds all modules it has collected. However, you can select a subset of these modules to build using command line flags. @@ -263,14 +263,11 @@ The reactor then selects which modules t <p>The following command line switches are available:</p> <table border="0" class="table table-striped"> <thead> - <tr class="a"> <th>Long</th> <th>Short</th> <th>Summary</th> -<th>Details</th></tr> -</thead><tbody> - +<th>Details</th></tr></thead><tbody> <tr class="b"> <td align="left"><code>--file</code></td> <td><code>-f</code></td> @@ -320,22 +317,19 @@ The reactor then selects which modules t <td align="left"><code>--fail-never</code></td> <td><code>-fn</code></td> <td>Never fails the build, regardless of the project result.</td> -<td><a href="#dealing-with-failures">Dealing with failures</a></td></tr> -</tbody> -</table></section><section> +<td><a href="#dealing-with-failures">Dealing with failures</a></td></tr></tbody> +</table> +</section><section> <h2><a name="Differences_between_Maven_3_and_4"></a>Differences between Maven 3 and 4</h2> <p><img src="multi-module.png" alt="Sample multi-module project" /></p> <p>The table below illustrates multiple scenarios which have changed between Maven 3 and 4. They assume a project structure as depicted above.</p> <table border="0" class="table table-striped"> <thead> - <tr class="a"> <th>Scenario</th> <th>Outcome (in order)</th> <th>Maven 3</th> -<th>Maven 4</th></tr> -</thead><tbody> - +<th>Maven 4</th></tr></thead><tbody> <tr class="b"> <td align="left">Build an aggregator and its children</td> <td>module-c, module-c-1, module-c-2</td> @@ -365,14 +359,14 @@ The reactor then selects which modules t <td align="left">Run specific goal on one submodule with dependencies from project</td> <td>module-c-2</td> <td><code>mvn install && mvn jetty:run -f module-c/module-c-2</code></td> -<td><code>mvn compile && mvn jetty:run -f module-c/module-c-2</code></td></tr> -</tbody> -</table></section><section> +<td><code>mvn compile && mvn jetty:run -f module-c/module-c-2</code></td></tr></tbody> +</table> +</section><section> <h2><a name="More_information"></a>More information</h2> <ul> -<li><a class="externalLink" href="http://books.sonatype.com/mvnex-book/reference/multimodule.html";>Chapter 6. A Multi-module Project (Maven by Example)</a> - does not include Maven 4 changes!</li> -</ul></section> +<li><a href="http://books.sonatype.com/mvnex-book/reference/multimodule.html"; class="externalLink">Chapter 6. A Multi-module Project (Maven by Example)</a> - does not include Maven 4 changes!</li> +</ul></section></section> </main> </div> </div> Modified: maven/website/content/guides/mini/guide-multiple-modules.html ============================================================================== --- maven/website/content/guides/mini/guide-multiple-modules.html (original) +++ maven/website/content/guides/mini/guide-multiple-modules.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/guides/mini/guide-multiple-modules.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-multiple-modules.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="Brett Porter Karl Heinz Marbaise" /> <meta name="date" content="2015-03-13" /> @@ -156,16 +156,16 @@ Karl Heinz Marbaise" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_to_Working_with_Multiple_Modules"></a>Guide to Working with Multiple Modules</h2> +<h1><a name="Guide_to_Working_with_Multiple_Modules"></a>Guide to Working with Multiple Modules</h1> <p>(If you're working with Maven 4, please refer to the <a href="./guide-multiple-modules-4.html"> Maven 4 edition of this guide</a>)</p> <p>As seen in the introduction to the POM, Maven supports project aggregation in addition to project inheritance. This section outlines how Maven processes projects with multiple modules, and how you can work with them more effectively.</p><section> -<h3><a name="The_Reactor"></a>The Reactor</h3> +<h2><a name="The_Reactor"></a>The Reactor</h2> <p>The mechanism in Maven that handles multi-module projects is referred to as the <i>reactor</i>. This part of the Maven core does the following:</p> <ul> <li>Collects all the available modules to build</li> <li>Sorts the projects into the correct build order</li> <li>Builds the selected projects in order</li></ul><section> -<h4><a name="Reactor_Sorting"></a>Reactor Sorting</h4> +<h3><a name="Reactor_Sorting"></a>Reactor Sorting</h3> <p>Because modules within a multi-module build can depend on each other, it is important that the reactor sorts all the projects in a way that guarantees any project is built before it is required.</p> <p>The following relationships are honoured when sorting projects:</p> <ul> @@ -175,7 +175,7 @@ Karl Heinz Marbaise" /> <li>a build extension declaration on another module in the build</li> <li>the order declared in the <code><modules></code> element (if no other rule applies)</li></ul> <p>Note that only "instantiated" references are used - <code>dependencyManagement</code> and <code>pluginManagement</code> elements do not cause a change to the reactor sort order.</p></section><section> -<h4><a name="Command_Line_Options"></a>Command Line Options</h4> +<h3><a name="Command_Line_Options"></a>Command Line Options</h3> <p>No special configuration is required to take advantage of the reactor, however it is possible to customize its behavior.</p> <p>The following command line switches are available:</p> <ul> @@ -186,7 +186,7 @@ Karl Heinz Marbaise" /> <li><code>--fail-at-end</code> - if a particular module build fails, continue the rest of the reactor and report all failed modules at the end instead</li> <li><code>--non-recursive</code> - do not use a reactor build, even if the current project declares modules and just build the project in the current directory</li></ul> <p>Refer to the Maven command line interface reference for more information on these switches.</p></section></section><section> -<h3><a name="More_information"></a>More information</h3> +<h2><a name="More_information"></a>More information</h2> <ul> <li><a class="externalLink" href="http://books.sonatype.com/mvnex-book/reference/multimodule.html";> Chapter 6. A Multi-module Project (Maven by Example)</a></li></ul></section></section> </main> Modified: maven/website/content/guides/mini/guide-multiple-repositories.html ============================================================================== --- maven/website/content/guides/mini/guide-multiple-repositories.html (original) +++ maven/website/content/guides/mini/guide-multiple-repositories.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/guides/mini/guide-multiple-repositories.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-multiple-repositories.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="Jason van Zyl" /> <meta name="date" content="2005-10-12" /> <title>Maven – Guide to using Multiple Repositories</title> @@ -153,7 +153,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Setting_up_Multiple_Repositories"></a>Setting up Multiple Repositories</h2> +<h1><a name="Setting_up_Multiple_Repositories"></a>Setting up Multiple Repositories</h1> <p>There are two different ways that you can specify the use of multiple repositories. The first way is to specify in a POM which repositories you want to use. That is supported both inside and outside of build profiles:</p> <div class="source"><pre class="prettyprint linenums"> <project> @@ -206,7 +206,7 @@ mvn -Pmyprofile ... </pre></div> <p>In fact the <code>-P</code> option will take a CSV list of profiles to activate if you wish to activate multiple profiles simultaneously.</p> <p><b>Note</b>: The settings descriptor documentation can be found on the <a href="../../maven-settings/settings.html">Maven Local Settings Model Website</a>.</p><section> -<h3><a name="Repository_Order"></a>Repository Order</h3> +<h2><a name="Repository_Order"></a>Repository Order</h2> <p>Remote repository URLs are queried in the following order for artifacts until one returns a valid result:</p> <ol style="list-style-type: decimal"> <li>effective settings: Modified: maven/website/content/guides/mini/guide-naming-conventions.html ============================================================================== --- maven/website/content/guides/mini/guide-naming-conventions.html (original) +++ maven/website/content/guides/mini/guide-naming-conventions.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/guides/mini/guide-naming-conventions.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-naming-conventions.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="Carlos Sanchez" /> <meta name="date" content="2005-11-01" /> <title>Maven – Guide to Naming Conventions</title> @@ -146,7 +146,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_to_naming_conventions_on_groupId.2C_artifactId.2C_and_version"></a>Guide to naming conventions on groupId, artifactId, and version</h2> +<h1><a name="Guide_to_naming_conventions_on_groupId.2C_artifactId.2C_and_version"></a>Guide to naming conventions on groupId, artifactId, and version</h1> <ul> <li><b>groupId</b> uniquely identifies your project across all projects. A group ID should follow <a class="externalLink" href="https://docs.oracle.com/javase/specs/jls/se6/html/packages.html#7.7";>Java's package name rules</a>. This means it starts with a reversed domain name you control. For example, <p><code>org.apache.maven</code>, <code>org.apache.commons</code></p> Modified: maven/website/content/guides/mini/guide-new-committers.html ============================================================================== --- maven/website/content/guides/mini/guide-new-committers.html (original) +++ maven/website/content/guides/mini/guide-new-committers.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/guides/mini/guide-new-committers.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-new-committers.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="Jason van Zyl" /> <meta name="date" content="2005-11-20" /> <title>Maven – Guide for new committers</title> @@ -124,7 +124,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_for_new_committers"></a>Guide for new committers</h2> +<h1><a name="Guide_for_new_committers"></a>Guide for new committers</h1> <p>First thing is to sort out some administrative tasks. Before your account is created and commit access granted you must complete and fax back to Apache the <a class="externalLink" href="http://www.apache.org/licenses/#clas";>Committer's License Agreement</a>.</p> <p>While this process is sorting itself out it is recommended that you peruse the various guides provided by Apache. All the guides are located in the <a class="externalLink" href="http://www.apache.org/dev/";>Development Infrastructure Information</a>.</p> <p>Of particular interest is the <a class="externalLink" href="http://www.apache.org/dev/committers.html";>Committer's FAQ</a> and the <a class="externalLink" href="http://www.apache.org/dev/new-committers-guide.html";>New Committer's Guide</a>.</p> Modified: maven/website/content/guides/mini/guide-proxies.html ============================================================================== --- maven/website/content/guides/mini/guide-proxies.html (original) +++ maven/website/content/guides/mini/guide-proxies.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/guides/mini/guide-proxies.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-proxies.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="Jason van Zyl" /> <meta name="date" content="2005-10-12" /> <title>Maven – Guide to using proxies</title> @@ -153,7 +153,7 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Configuring_a_proxy"></a>Configuring a proxy</h2> +<h1><a name="Configuring_a_proxy"></a>Configuring a proxy</h1> <p>You can configure a proxy to use for some or all of your HTTP requests with Maven. The username and password are only required if your proxy requires basic authentication (note that later releases may support storing your passwords in a secured keystore - in the mean time, please ensure your settings.xml file (usually ${user.home}/.m2/settings.xml) is secured with permissions appropriate for your operating system).</p> <p>The <code>nonProxyHosts</code> setting accepts wild cards, and each host not to proxy is separated by the | character. This matches the JDK configuration equivalent.</p> <div class="source"><pre class="prettyprint linenums"> @@ -177,7 +177,7 @@ </settings> </pre></div> <p>Please note that currently NTLM proxies are not supported as they have not been tested. You may be able to use the relevant system properties on JDK 1.4+ to make this work.</p><section> -<h3><a name="Resources"></a>Resources</h3> +<h2><a name="Resources"></a>Resources</h2> <ol style="list-style-type: decimal"> <li><a href="../../maven-settings/settings.html">Settings descriptor documentation</a></li> <li><a href="./guide-configuring-maven.html">Configuring Maven</a></li></ol></section></section> Modified: maven/website/content/guides/mini/guide-releasing.html ============================================================================== --- maven/website/content/guides/mini/guide-releasing.html (original) +++ maven/website/content/guides/mini/guide-releasing.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/guides/mini/guide-releasing.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-releasing.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="Jason van Zyl Trent Rosenbaum Vincent Massol @@ -159,14 +159,14 @@ Karl Heinz Marbaise" /> </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Releasing"></a>Releasing</h2><section> -<h3><a name="Introduction"></a>Introduction</h3> +<h1><a name="Releasing"></a>Releasing</h1><section> +<h2><a name="Introduction"></a>Introduction</h2> <p>The main aim of the maven-release plugin is to provide a standard mechanism to release project artifacts outside the immediate development team. The plugin provides basic functionality to create a release and to update the project's SCM accordingly.</p> <p>To create a release the maven-release plugin is executed through maven in 2 stages:</p> <ol style="list-style-type: decimal"> <li>Preparing the release.</li> <li>Performing the release.</li></ol></section><section> -<h3><a name="Preparing_the_release"></a>Preparing the release</h3> +<h2><a name="Preparing_the_release"></a>Preparing the release</h2> <p>The plugin will record release information into a new revision of the project's <i>pom.xml</i> file as well as applying SCM versioning to the project's resources.</p> <p>The <code>release:prepare</code> goal will:</p> <ol style="list-style-type: decimal"> @@ -260,7 +260,7 @@ Karl Heinz Marbaise" /> <li><b>A New development version</b>. <p>This value is the placed in the next revision of the <i>pom.xml</i> file used for continuing development. If the current release represented version 1.0 then an appropriate value could be 2.0-SNAPSHOT. The SNAPSHOT designator is required to prepare and perform future releases. This value is then committed in the next development revision of the <i>pom.xml</i> file.</p></li></ul> <p>After maven has been supplied with the required information the maven-release plugin will interact with the project's SCM and define a relese to be extracted and deployed. At the same time the project's development trunk is updated allowing developers to continue with further modifications that will be included within future releases.</p></section><section> -<h3><a name="Performing_the_release"></a>Performing the release</h3> +<h2><a name="Performing_the_release"></a>Performing the release</h2> <p>The plugin will extract file revisions associated with the current release. Maven will compile, test and package the versioned project source code into an artifact. The final deliverable will then be released into an appropriate maven repository.</p> <p>The <code>release:perform</code> goal will:</p> <ol style="list-style-type: decimal"> @@ -319,10 +319,10 @@ checkpoint.check-in-development-version= <p>The source code revisions used to build the current release of the project.</p></li> <li><i>artifact id</i>-<i>version</i>.pom <p>The contents of the <i>pom.xml</i> file used to create the current release of the project.</p></li></ul></section><section> -<h3><a name="Troubleshooting"></a>Troubleshooting</h3><section> -<h4><a name="I_get_a_.22The_authenticity_of_host_.27host.27_can.27t_be_established..22_error_and_the_build_hangs"></a>I get a "The authenticity of host '<i>host</i>' can't be established." error and the build hangs</h4> +<h2><a name="Troubleshooting"></a>Troubleshooting</h2><section> +<h3><a name="I_get_a_.22The_authenticity_of_host_.27host.27_can.27t_be_established..22_error_and_the_build_hangs"></a>I get a "The authenticity of host '<i>host</i>' can't be established." error and the build hangs</h3> <p>This is because your <code>~user/.ssh/known_hosts</code> file doesn't have the host listed. You'd normally get a prompt to add the host to the known host list but Maven doesn't propagate that prompt. The solution is to add the host the <code>known_hosts</code> file before executing Maven. On Windows, this can be done by installing an OpenSSH client (for example <a class="externalLink" href="http://sshwindows.sourceforge.net/download/";>SSHWindows</a>), running <code>ssh <host</code>> and accepting to add the host.</p></section><section> -<h4><a name="The_site_deploy_goal_hangs"></a>The site deploy goal hangs</h4> +<h3><a name="The_site_deploy_goal_hangs"></a>The site deploy goal hangs</h3> <p>First, this means that you have successfully deployed the artifacts to the remote repo and that it's only the site deployment that is now an issue. Stop your build, cd to <b>target/checkout</b>> and run the build again by executing <code>mvn site:deploy</code>. You should see a prompt asking you to enter a password. This happens if your key is not in the authorized keys on the server.</p></section></section></section> </main> </div> Modified: maven/website/content/guides/mini/guide-relocation.html ============================================================================== --- maven/website/content/guides/mini/guide-relocation.html (original) +++ maven/website/content/guides/mini/guide-relocation.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/guides/mini/guide-relocation.apt at 2022-08-20 + | Generated by Apache Maven Doxia Site Renderer 2.0.0-M3 from content/apt/guides/mini/guide-relocation.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" /> <meta name="date" content="2006-07-08" /> <title>Maven – Guide to relocation</title> @@ -153,13 +153,13 @@ </header> <main id="bodyColumn" class="span10" > <section> -<h2><a name="Guide_to_relocation"></a>Guide to relocation</h2> +<h1><a name="Guide_to_relocation"></a>Guide to relocation</h1> <p>Sometimes it is necessary to relocate artifacts in the repository. One example of that is when a project moves from one groupId to a different groupId.</p> <p>Making changes to the repository can have far reaching consequences. So it is best to get it right the first time, hence this guide.</p> <p><b>2020 rework in progress</b>, see <a class="externalLink" href="https://lists.apache.org/thread.html/r5e940260cfe5234f540c20fdb7bb7dacbb63b911a4b902c75f4f0cd2%40%3Cdev.maven.apache.org%3E";>discussion on dev mailing list</a>, still need analysis of issues, definition of improvements, and of course implementation...</p><section> -<h3><a name="How_to_relocate_a_Maven_2_artifact_to_a_different_groupId"></a>How to relocate a Maven 2 artifact to a different groupId</h3> +<h2><a name="How_to_relocate_a_Maven_2_artifact_to_a_different_groupId"></a>How to relocate a Maven 2 artifact to a different groupId</h2> <p>The goal of the example below is for the <code>foo</code> project to relocate its groupId from <code>bar</code> to <code>org.bar</code>.</p><section> -<h4><a name="Working_on_past_versions"></a>Working on past versions</h4> +<h3><a name="Working_on_past_versions"></a>Working on past versions</h3> <ol style="list-style-type: decimal"> <li>Copy all <code>foo</code>-related files from <code>/bar/foo/</code> in your Maven 2 repository to a temporary location.</li> <li>Change the groupId to <code>org.bar</code> in all <code>foo</code>-related POM files in the temporary location.</li> @@ -182,18 +182,18 @@ <li>If your project uses MD5 or SHA1 checksums you must now create new checksums for the pom files in <code>/bar/foo/</code> in your Maven 2 repository. If the POM file needs to be signed, do that as well.</li> <li>If your project syncs with Central, you should now initiate that sync. This might happen automatically depending on your projects sync policy.</li></ol> <p>Your <code>foo</code>-artifacts are now available to Maven users with both the old and the new groupId. Projects using the old groupId will automatically be redirected to the new groupId and a warning telling the user to update their dependencies will be issued.</p></section><section> -<h4><a name="Releasing_the_next_version"></a>Releasing the next version</h4> +<h3><a name="Releasing_the_next_version"></a>Releasing the next version</h3> <p>When the next release of <code>foo</code> is made, you should publish two Maven 2 POM files: first you should publish <code>foo</code>'s POM with the new groupId <code>org.bar</code>.</p> <p>Because data in the repository is not supposed to change, Maven doesn't download POM files that it has already downloaded. Therefore you will also need to publish a relocation POM file with the old groupId <code>bar</code> for the new version: this should be a minimal relocation POM (as described in step 4 above), but for the new version of <code>foo</code>.</p> <p>For the release after that, you only need to publish a Maven POM with a groupId of <code>org.bar</code>, since users of the previous version have been informed of the changed groupId.</p></section></section><section> -<h3><a name="Examples"></a>Examples</h3><section> -<h4><a name="Apache_Ant"></a>Apache Ant</h4> +<h2><a name="Examples"></a>Examples</h2><section> +<h3><a name="Apache_Ant"></a>Apache Ant</h3> <ol style="list-style-type: decimal"> <li>has published its releases until 1.6.5 to Maven 1-compliant <code>ant:ant</code> coordinates (see <a class="externalLink" href="https://repo.maven.apache.org/maven2/ant/ant/";>repository content</a>),</li> <li>starting with 1.7.0, moved to reverse-DNS compliant Maven 2+ <code>org.apache.ant:ant</code> coordinates, (see <a class="externalLink" href="https://repo.maven.apache.org/maven2/org/apache/ant/ant/";>repository content</a>),</li> <li>published one <code>ant:ant:1.7.0</code> relocation POM in old groupId to advertise about the move (see <a class="externalLink" href="https://repo.maven.apache.org/maven2/ant/ant/1.7.0/";>repository content</a>).</li></ol> <p>Notice that past <code>ant:ant</code> versions POMs (until 1.6.5) have not been modified to advertise about the move: Central POM content is not expected to be changed once published (because initial content has been downloaded many times and is not expected to be re-loaded later).</p></section><section> -<h4><a name="Apache_POI"></a>Apache POI</h4> +<h3><a name="Apache_POI"></a>Apache POI</h3> <ol style="list-style-type: decimal"> <li>has published its releases until 3.0-alpha-3 to Maven 1-compliant <code>poi:poi</code> coordinates (see <a class="externalLink" href="https://repo.maven.apache.org/maven2/poi/poi/";>repository content</a>),</li> <li>starting with 3.0-FINAL, moved to reverse-DNS compliant Maven 2+ <code>org.apache.poi:poi</code> coordinates, (see <a class="externalLink" href="https://repo.maven.apache.org/maven2/org/apache/poi/poi/";>repository content</a>),</li>
