svn commit: r1870256 - in /maven/website/content: guides/mini/guide-relocation.html maven-site-1.0-site.jar

[sv...@apache.org]

Author: svn-site-role
Date: Sat Nov 23 18:58:46 2019
New Revision: 1870256

Log:
Site checkin for project Apache Maven Site

Modified:
    maven/website/content/guides/mini/guide-relocation.html
    maven/website/content/maven-site-1.0-site.jar

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 Nov 23 18:58:46 2019
@@ -145,23 +145,8 @@
         <main id="bodyColumn"  class="span10" >
 <section>
 <h2><a name="Guide_to_relocation"></a>Guide to relocation</h2>
-<p>Sometimes it is necessary to relocate artifacts in the repository. One example of that is when a project moves from Maven 1 to Maven 2. Maven 1 projects have traditionally used a flat repository structure, while Maven 2 uses a deep repository structure. As an example the Maven 1 project has a groupId of <code>maven</code> while the Maven 2 project has a groupId of <code>org.apache.maven</code>.</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. It will go through a couple of different kinds of relocations:</p>
-<ul>
-<li>Maven 1 to Maven 1</li>
-<li>Maven 2 to Maven 2</li>
-<li>Maven 1 to Maven 2</li></ul>
+<p>Sometimes it is necessary to relocate artifacts in the repository. One example of that is when a project moves from one groupId to different groupId. 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>The goal of the examples below is to relocate the groupId from <code>bar</code> to <code>org.bar</code> for the <code>foo</code> project.</p><section>
-<h3><a name="How_to_relocate_a_Maven_1_artifact_to_a_different_groupId"></a>How to relocate a Maven 1 artifact to a different groupId</h3>
-<ol style="list-style-type: decimal">
-<li>Copy all <code>foo</code>-related files from <code>/bar/</code> in your Maven 1 repository to a temporary location.</li>
-<li>Change the groupId to <code>org.bar</code> in all the <code>foo</code>-related pom files in the temporary location.</li>
-<li>If your project uses MD5 or SHA1 checksums you must now create new checksums for the changed pom files in the temporary location. If the pom file needs to be signed, do that as well.</li>
-<li>Copy all files from the temporary location to <code>/org.bar/</code> in your Maven 1 repository.</li>
-<li>If your project syncs with ibiblio, 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 1 users with both the old and the new groupId.</p><section>
-<h4><a name="Releasing_the_next_version"></a>Releasing the next version</h4>
-<p>When the next release of <code>foo</code> is made, you publish the Maven 1 pom as you have always done. Unfortunately Maven 1 does not have a concept of automatic relocation and notification, so you will have to inform your users of the changed groupId through your regular information channels.</p></section></section><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>
 <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>
@@ -183,17 +168,12 @@
 &lt;/project&gt;</pre></div>
 <p>In this case we are relocating because the groupId has changed. We only need to add the element that has changed to the <code>relocation</code> element. For information on which elements are allowed in the <code>relocation</code> element, see <a href="/ref/current/maven-model/maven.html#class_relocation">the pom reference</a>.</p></li>
 <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 ibiblio, 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 2 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>
+<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>
 <h4><a name="Releasing_the_next_version"></a>Releasing the next version</h4>
 <p>When the next release of <code>foo</code> is made, you should publish two Maven 2 pom files. First you should publish a pom with the new groupId <code>org.bar</code>.</p>
-<p>Because data in the repository is not supposed to change, Maven 2 doesn't download pom files that it has already downloaded. Therefore you will also need to publish a 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 2 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="How_to_relocate_a_Maven_1_artifact_to_a_Maven_2_artifact_with_a_different_groupId"></a>How to relocate a Maven 1 artifact to a Maven 2 artifact with a different groupId</h3>
-<p><i>This is only of interest to organizations (like the Apache Software Foundation) that automatically converts the contents of their Maven 1 repository to their Maven 2 repository.</i></p>
-<p>Follow steps 4 to 6 in the section <i>How to relocate a Maven 2 artifact to a different groupId</i> above.</p><section>
-<h4><a name="Releasing_the_next_version"></a>Releasing the next version</h4>
-<p>When the next release of <code>foo</code> is made, you should publish the Maven 1 pom as you have always done. In addition to that, you should publish a Maven 2 pom with a groupId of <code>bar</code>, a version of &lt;next-version&gt; and include a relocation section. This step can be done once for the first release of a project, after the groupId has been changed, but your users will be happier if you do it more times.</p></section></section></section>
+<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 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>
         </main>
       </div>
     </div>

Modified: maven/website/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.