This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
The following commit(s) were added to refs/heads/master by this push:
new 6d0dd6e Remove relocation content for Maven 1
6d0dd6e is described below
commit 6d0dd6ef7cb80547b129574abc58e6a49b068132
Author: Sylwester Lachiewicz <slachiew...@apache.org>
AuthorDate: Sat Nov 23 19:57:43 2019 +0100
Remove relocation content for Maven 1
---
content/apt/guides/mini/guide-relocation.apt | 72 +++-------------------------
1 file changed, 6 insertions(+), 66 deletions(-)
diff --git a/content/apt/guides/mini/guide-relocation.apt
b/content/apt/guides/mini/guide-relocation.apt
index 9da4e0d..8b59734 100644
--- a/content/apt/guides/mini/guide-relocation.apt
+++ b/content/apt/guides/mini/guide-relocation.apt
@@ -29,56 +29,14 @@
Guide to relocation
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 <<<maven>>> while the Maven 2 project has a groupId of
<<<org.apache.maven>>>.
-
+ 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. It will go through a
- couple of different kinds of relocations:
-
- * Maven 1 to Maven 1
-
- * Maven 2 to Maven 2
-
- * Maven 1 to Maven 2
+ best to get it right the first time, hence this guide.
[]
The goal of the examples below is to relocate the groupId from <<<bar>>> to
<<<org.bar>>> for the <<<foo>>> project.
-
-* How to relocate a Maven 1 artifact to a different groupId
-
- [[1]] Copy all <<<foo>>>-related files from <<</bar/>>> in your Maven 1
repository
- to a temporary location.
-
- [[2]] Change the groupId to <<<org.bar>>> in all the <<<foo>>>-related pom
files in
- the temporary location.
-
- [[3]] 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.
-
- [[4]] Copy all files from the temporary location to <<</org.bar/>>> in your
- Maven 1 repository.
-
- [[5]] If your project syncs with ibiblio, you should now initiate that sync.
- This might happen automatically depending on your projects sync policy.
-
- []
-
- Your <<<foo>>>-artifacts are now available to Maven 1 users with both the old
and
- the new groupId.
-
-** Releasing the next version
-
- When the next release of <<<foo>>> 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.
-
* How to relocate a Maven 2 artifact to a different groupId
@@ -124,12 +82,12 @@ Guide to relocation
the pom files in <<</bar/foo/>>> in your Maven 2 repository. If the pom file
needs
to be signed, do that as well.
- [[6]] If your project syncs with ibiblio, you should now initiate that sync.
+ [[6]] If your project syncs with Central, you should now initiate that sync.
This might happen automatically depending on your projects sync policy.
[]
- Your <<<foo>>>-artifacts are now available to Maven 2 users with both the old
+ Your <<<foo>>>-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.
@@ -139,31 +97,13 @@ Guide to relocation
When the next release of <<<foo>>> is made, you should publish two Maven 2 pom
files. First you should publish a pom with the new groupId <<<org.bar>>>.
- Because data in the repository is not supposed to change, Maven 2 doesn't
+ 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 <<<bar>>> for the new version. This
should be a minimal relocation pom (as described in step 4 above), but for the
new version of <<<foo>>>.
- For the release after that, you only need to publish a Maven 2 pom with a
+ For the release after that, you only need to publish a Maven pom with a
groupId of <<<org.bar>>>, since users of the previous version have been
informed of the changed groupId.
-
-* How to relocate a Maven 1 artifact to a Maven 2 artifact with a different
groupId
-
- <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.>
-
- Follow steps 4 to 6 in the section <How to relocate a Maven 2 artifact to a
- different groupId> above.
-
-** Releasing the next version
-
- When the next release of <<<foo>>> 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 <<<bar>>>, a version of \<next-version\> 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.
