Maven GroupID authority

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven GroupID authority

Jonathan Valliere
I have been growing concerned about the process of allowing the creation of
GroupIDs, within the Maven Central repository, which do not adhere to the
naming guidelines. i.e. the GroupID must belong to a unique domain name
controlled by the project owner.

Even within the Apache family, there is no consistent naming enforcement.
The project I belong to, org.apache.mina adheres to the conventions but
many others do not.  Apache Commons for example uses a different GroupID
for almost every sub-project within its scope.  Many of them simply
starting with the word "commons" instead of "org.apache.commons".  Does the
PMC have any ideas on how to combat this?

Cheers,
Jon
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Jonathan Valliere
Is there any kind of planned timeline to force compliance against old
projects?

For example:

   - Force compliance
   - Provide symlinks for backwards compatibility for a limited period of
   time (1 year)
   - Update Maven clients to provide warnings for symlinks during
   builds/tests/etc


On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser <[hidden email]>
wrote:

> This is a left over from bad choices made decades ago. Now Maven Central
> has well documented criteria ... very contrary to nearly all other binary
> repos..
>
>
> https://central.sonatype.org/pages/ossrh-guide.html
>
> https://central.sonatype.org/pages/requirements.html#correct-coordinates
>
> And the videos linked on the site in which I explain more as well.
>
> Manfred
>
>
> Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):
>
> > I have been growing concerned about the process of allowing the creation
> of
> > GroupIDs, within the Maven Central repository, which do not adhere to the
> > naming guidelines. i.e. the GroupID must belong to a unique domain name
> > controlled by the project owner.
> >
> > Even within the Apache family, there is no consistent naming enforcement.
> > The project I belong to, org.apache.mina adheres to the conventions but
> > many others do not.  Apache Commons for example uses a different GroupID
> > for almost every sub-project within its scope.  Many of them simply
> > starting with the word "commons" instead of "org.apache.commons".  Does
> the
> > PMC have any ideas on how to combat this?
> >
> > Cheers,
> > Jon
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Sander Verhagen
Hi, y'all. (Disclaimer: I may not completely understand you're proposing.) I wonder what problem you are really trying to solve. People by now have lost the absolute expectation that the groupId is authoritative or certified in any way. And the way that projects get moved between owners, without breaking dependency resolution, would become a nightmare when it'd require a change to groupIds. Also, please don't force projects to change their groupId/artifactId combos. We are still struggling with dependency issues because of having multiple versions of the (essentially) same dependency on our classpath, because a groupId/artifactId got changed (sometimes a decade ago). If you can drive better behavior going forward, all the better, but other than that, and while I also like it when the world is nicely organized (groupId/artifactId), there seems little to win here (and a lot to loose).

Best regards, Sander.



Sander Verhagen
[  [hidden email]<mailto:[hidden email]>  ]

On 13/02/2020 19.28, Jonathan Valliere wrote:

Is there any kind of planned timeline to force compliance against old
projects?

For example:

   - Force compliance
   - Provide symlinks for backwards compatibility for a limited period of
   time (1 year)
   - Update Maven clients to provide warnings for symlinks during
   builds/tests/etc


On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser <[hidden email]><mailto:[hidden email]>
wrote:



This is a left over from bad choices made decades ago. Now Maven Central
has well documented criteria ... very contrary to nearly all other binary
repos..


https://central.sonatype.org/pages/ossrh-guide.html

https://central.sonatype.org/pages/requirements.html#correct-coordinates

And the videos linked on the site in which I explain more as well.

Manfred


Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):



I have been growing concerned about the process of allowing the creation


of


GroupIDs, within the Maven Central repository, which do not adhere to the
naming guidelines. i.e. the GroupID must belong to a unique domain name
controlled by the project owner.

Even within the Apache family, there is no consistent naming enforcement.
The project I belong to, org.apache.mina adheres to the conventions but
many others do not.  Apache Commons for example uses a different GroupID
for almost every sub-project within its scope.  Many of them simply
starting with the word "commons" instead of "org.apache.commons".  Does


the


PMC have any ideas on how to combat this?

Cheers,
Jon




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]<mailto:[hidden email]>
For additional commands, e-mail: [hidden email]<mailto:[hidden email]>







Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Manfred Moser-4
Agreed ... which is why no one ever went down that road in the last decade...

Sander Verhagen wrote on 2020-02-13 19:35 (GMT -08:00):

> Hi, y'all. (Disclaimer: I may not completely understand you're proposing.) I
> wonder what problem you are really trying to solve. People by now have lost the
> absolute expectation that the groupId is authoritative or certified in any way.
> And the way that projects get moved between owners, without breaking dependency
> resolution, would become a nightmare when it'd require a change to groupIds.
> Also, please don't force projects to change their groupId/artifactId combos. We
> are still struggling with dependency issues because of having multiple versions
> of the (essentially) same dependency on our classpath, because a
> groupId/artifactId got changed (sometimes a decade ago). If you can drive
> better behavior going forward, all the better, but other than that, and while I
> also like it when the world is nicely organized (groupId/artifactId), there
> seems little to win here (and a lot to loose).
>
> Best regards, Sander.
>
>
>
> Sander Verhagen
> [  [hidden email]<mailto:[hidden email]>  ]
>
> On 13/02/2020 19.28, Jonathan Valliere wrote:
>
> Is there any kind of planned timeline to force compliance against old
> projects?
>
> For example:
>
>   - Force compliance
>   - Provide symlinks for backwards compatibility for a limited period of
>   time (1 year)
>   - Update Maven clients to provide warnings for symlinks during
>   builds/tests/etc
>
>
> On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser
> <[hidden email]><mailto:[hidden email]>
> wrote:
>
>
>
> This is a left over from bad choices made decades ago. Now Maven Central
> has well documented criteria ... very contrary to nearly all other binary
> repos..
>
>
> https://central.sonatype.org/pages/ossrh-guide.html
>
> https://central.sonatype.org/pages/requirements.html#correct-coordinates
>
> And the videos linked on the site in which I explain more as well.
>
> Manfred
>
>
> Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):
>
>
>
> I have been growing concerned about the process of allowing the creation
>
>
> of
>
>
> GroupIDs, within the Maven Central repository, which do not adhere to the
> naming guidelines. i.e. the GroupID must belong to a unique domain name
> controlled by the project owner.
>
> Even within the Apache family, there is no consistent naming enforcement.
> The project I belong to, org.apache.mina adheres to the conventions but
> many others do not.  Apache Commons for example uses a different GroupID
> for almost every sub-project within its scope.  Many of them simply
> starting with the word "commons" instead of "org.apache.commons".  Does
>
>
> the
>
>
> PMC have any ideas on how to combat this?
>
> Cheers,
> Jon
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]<mailto:[hidden email]>
> For additional commands, e-mail:
> [hidden email]<mailto:[hidden email]>
>
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Christian Stein
On Fri, Feb 14, 2020 at 6:37 AM Manfred Moser <[hidden email]>
wrote:

> From the very start of the work on the module system and throughout the
> work people from the Maven project have been involved.
>
> There was never a willingness to create any sort of enforcement.. only a
> request to the community to do the right thing
>
> From my point of view the Maven project can not do anything really.
>
>
Except for doing some related sanity checks, like [0]. (-:
As of today, there are already 13263 artifacts at Maven Central with
invalid module names, due to not checking the "Automatic-Module-Name"
manifest attribute.
More details at [1], the daily-updated index of "unique" Java modules
published to Maven Central.

Perhaps "we" should guide users to adhere to name their Maven artifacts
like the Java module it contains. And start the artifact name with the
Group ID...
More details about this naming convention proposal at [2].

Cheers,
Christian

[0] https://issues.apache.org/jira/browse/MSHARED-773
[1] https://github.com/sormuras/modules#suspicious-modules
[2]
https://sormuras.github.io/blog/2019-08-04-maven-coordinates-and-java-module-names.html
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Christian Stein
In reply to this post by Jonathan Valliere
On Fri, Feb 14, 2020 at 8:11 AM Hervé BOUTEMY <[hidden email]> wrote:

> on that precise case ("commons" instead of "org.apache.commons"), it's
> from
> past Maven 1 repository format time.
>
> then such case is not added to Central for years, only projects that
> existed
> at early Maven 1 repository time (like junit, for example or other
> commons)
> have such names: it's up to each of those veteran projects to choose to
> move
> from their old Maven 1 compliant coordinates to full groupId.
>
> If you know such veteran projects that did not move, just share and tell
> them.
>
>
As "junit" was explicitly mentioned as an example for a vintage (pun
intended)
project here's our reasoning to stick with that very short name ...
forever. At least
for the JUnit 4 (and 3) project artifacts. Including Automatic-Module-Name
attribute introduced in JUnit 4.13:
https://github.com/junit-team/junit4/pull/1571

   - junit - Maven Group ID
   - junit - Artifact ID
   - junit - Java Module Name


JUnit "5", precisely JUnit Platform, Jupiter, and Vintage moved to the
reversed DNS
naming pattern since there day one:

- https://repo.maven.apache.org/maven2/org/junit/platform/
- https://repo.maven.apache.org/maven2/org/junit/jupiter/
- https://repo.maven.apache.org/maven2/org/junit/vintage/

Cheers,
Christian
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

rfscholte
In reply to this post by Jonathan Valliere
I'd prefer to make a clear distinction between the build tool and the shared repositories like Maven Central.
Here the problem should be solved by the latter.

And it is:
https://central.sonatype.org/pages/choosing-your-coordinates.html

Unlike module names, you must claim a groupId before pushing it to Maven Central.
Central contains some bad picked groupId from the early days, but now that most are used to the value of a groupId, I don't see a real risk here.

Robert
On 14-2-2020 02:07:03, Jonathan Valliere <[hidden email]> wrote:
I have been growing concerned about the process of allowing the creation of
GroupIDs, within the Maven Central repository, which do not adhere to the
naming guidelines. i.e. the GroupID must belong to a unique domain name
controlled by the project owner.

Even within the Apache family, there is no consistent naming enforcement.
The project I belong to, org.apache.mina adheres to the conventions but
many others do not. Apache Commons for example uses a different GroupID
for almost every sub-project within its scope. Many of them simply
starting with the word "commons" instead of "org.apache.commons". Does the
PMC have any ideas on how to combat this?

Cheers,
Jon
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Jonathan Valliere
In reply to this post by Jonathan Valliere
If Central indicated a redirect/reallocation then there would never be the
duplicate classpath problem because Maven would resolve it internally.  The
redirect then warns the user of the redirect and to update the pom.

On Sat, Feb 15, 2020 at 1:10 PM Elliotte Rusty Harold <[hidden email]>
wrote:

> On Sat, Feb 15, 2020 at 10:55 AM Jonathan Valliere
> <[hidden email]> wrote:
> >
> > How would changing the GroupID cause diamond dependencies?  The builds
> > would just fail everywhere until the GroupID is updated in the pom files.
>
> No, they wouldn't. What happens is two artifacts get added to the
> classpath, one with the new group ID and one with the old group ID. In
> Java 8 and earlier the program will continue to compile and run until
> some code that depends on the newer version happens to get a class
> from the older version or vice versa. It's a mess.
>
> In Java 9 and later the failure happens earlier and more reliably but
> it's still confusing and difficult to debug and fix.
>
> > One thing I suggested was to create a new ID with all the old versions
> > going back in time and simply redirect the old ID to the new one and mark
> > it as deprecated/locked somehow so anytime you run Maven you get a big
> > warning about the deprecated GroupID and the suggestion how to fix the
> pom.
> > After a few years simply kill off the old GroupID.
>
> Nope. A fundamental principle of the Maven repository system is that
> once an artifact is published it's there forever and will not change.
> There've been a very few exceptions here and there over the years, but
> simply eliminating group IDs en masse. That's close to closing down
> the central repository completely.
>
> > The other issue is Artifacts and Automodule names. Automodules are going
> to
> > be around for a long time because no one wants to build two jars for pre
> > and post J9.
> >
>
> True enough, but a Java 8 jar can still have an explicit module name.
> It's just one more entry in the MANIFEST.MF that pre-9 VMs are happy
> to ignore. We can't go back and add module names to old jars but it's
> worth adding explicit module names in new versions going forward.
>
> --
> Elliotte Rusty Harold
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Elliotte Rusty Harold
In reply to this post by Jonathan Valliere
On Sun, Feb 16, 2020 at 2:35 AM <[hidden email]> wrote:
>
> see:
> - http://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_relocation
> - https://maven.apache.org/guides/mini/guide-relocation.html
>

The guide to relocation seems to assume a lot more access and control
to the repo than is the case with public repositories like Maven
Central. I'm not sure it's actually possible to follow these steps
today, though perhaps that could be changed.

I'd still like to see the code in the repo that implements support for
this or, better yet, a sample project that demonstrates relocation is
possible.

If this does work, I can see a lot of use cases for it, but I'm
currently working with the assumption it is not.

--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Anders Hammar
In real practice it doesn't work well though, as someone already brought
up. It can result in duplication of libraries on the class path (the same
library under different groupId).

/Anders (mobile)

Den ons 19 feb. 2020 14:52Elliotte Rusty Harold <[hidden email]> skrev:

> I set up some simple projects and tested this manually. As best I can
> determine, relocation does work as one would hope, at least in Maven
> and M2E. (No idea about Gradle or Ivy.)
>
> The documentation should probably be rewritten because it assumes you
> can change published pom.xml files, which isn't true on Maven central.
>
> On Mon, Feb 17, 2020 at 3:36 PM Hervé BOUTEMY <[hidden email]>
> wrote:
> >
> > you can test with
> > https://repo.maven.apache.org/maven2/ant/ant/1.7.0/ant-1.7.0.pom
> > https://repo.maven.apache.org/maven2/javax/xml/jaxrpc/1.1/jaxrpc-1.1.pom
> >
> https://repo.maven.apache.org/maven2/javax/xml/jaxb-api/1.0.1/jaxb-api-1.0.1.pom
> >
> > testing relocation was on my todo list for years, but I never really test
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 16 février 2020, 15:18:17 CET Elliotte Rusty Harold a écrit :
> > > On Sun, Feb 16, 2020 at 2:35 AM <[hidden email]> wrote:
> > > > see:
> > > > -
> > > >
> http://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_relocation
> > > > - https://maven.apache.org/guides/mini/guide-relocation.html
> > >
> > > The guide to relocation seems to assume a lot more access and control
> > > to the repo than is the case with public repositories like Maven
> > > Central. I'm not sure it's actually possible to follow these steps
> > > today, though perhaps that could be changed.
> > >
> > > I'd still like to see the code in the repo that implements support for
> > > this or, better yet, a sample project that demonstrates relocation is
> > > possible.
> > >
> > > If this does work, I can see a lot of use cases for it, but I'm
> > > currently working with the assumption it is not.
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> --
> Elliotte Rusty Harold
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Jonathan Valliere
Just indicate a date in the pom at which point the relocation warning turns
into a relocation error. <expires>date</>. So you warn for a year then you
keep it up on central for an additional year in which it throws errors but
indicates to the redirection information.

On Thu, Feb 20, 2020 at 2:55 AM Hervé BOUTEMY <[hidden email]> wrote:

> +1
>
> probably will start by improving the documentation, because this is really
> the
> current intent from what I can understand: a relocation pom only provides
> relocation info only, no jar, no build info
>
> like https://repo.maven.apache.org/maven2/ant/ant/1.7.0/ that points to
> https://repo.maven.apache.org/maven2/org/apache/ant/ant/1.7.0/
>
> AFAIK, there is no modification expected on existing artifacts, just
> relocation
> poms to create at old coordinates to point new coordinates = the new
> canonical
> coordinates
>
>
> then perhaps the way it is implemented can be improved: one issue I can
> see
> (from a pure theoretical point of view, I didn't take time to make
> extensive
> tests) is to define when you stop publishing relocation poms at old
> coordinates, ie. starting with which version?
> and how to be sure that the relocation is detected when resolving both old
> coordinates and new coordinates that are both canonical coordinates?
>
> for example ant:ant:1.6.5 (= canonical coordinates for this release) and
> org.apache.ant:ant:1.8.0 (= canonical coordinates for this release), given
> there is no relocation pom published for ant:ant:1.8.0, only for
> ant:ant:1.7.0
>
> Regards,
>
> Hervé
>
> Le mercredi 19 février 2020, 16:48:38 CET Jonathan Valliere a écrit :
> > Maybe we need to rework how this functionality works.  It should be
> > essentially a symlink with a warning message within the resolver so they
> > both resolve to the same artifact.
> >
> > On Wed, Feb 19, 2020 at 8:58 AM Anders Hammar <[hidden email]> wrote:
> > > In real practice it doesn't work well though, as someone already
> brought
> > > up. It can result in duplication of libraries on the class path (the
> same
> > > library under different groupId).
> > >
> > > /Anders (mobile)
> > >
> > > Den ons 19 feb. 2020 14:52Elliotte Rusty Harold <[hidden email]>
> > >
> > > skrev:
> > > > I set up some simple projects and tested this manually. As best I can
> > > > determine, relocation does work as one would hope, at least in Maven
> > > > and M2E. (No idea about Gradle or Ivy.)
> > > >
> > > > The documentation should probably be rewritten because it assumes you
> > > > can change published pom.xml files, which isn't true on Maven
> central.
> > > >
> > > > On Mon, Feb 17, 2020 at 3:36 PM Hervé BOUTEMY <[hidden email]
> >
> > > >
> > > > wrote:
> > > > > you can test with
> > > > > https://repo.maven.apache.org/maven2/ant/ant/1.7.0/ant-1.7.0.pom
> > >
> > >
> https://repo.maven.apache.org/maven2/javax/xml/jaxrpc/1.1/jaxrpc-1.1.pom
> > >
> > >
> > >
> https://repo.maven.apache.org/maven2/javax/xml/jaxb-api/1.0.1/jaxb-api-1.0
> > > .1.pom>
> > > > > testing relocation was on my todo list for years, but I never
> really
> > >
> > > test
> > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le dimanche 16 février 2020, 15:18:17 CET Elliotte Rusty Harold a
> > >
> > > écrit :
> > > > > > On Sun, Feb 16, 2020 at 2:35 AM <[hidden email]> wrote:
> > > > > > > see:
> > > > > > > -
> > >
> > >
> http://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_relocation
> > >
> > > > > > > - https://maven.apache.org/guides/mini/guide-relocation.html
> > > > > >
> > > > > > The guide to relocation seems to assume a lot more access and
> > > > > > control
> > > > > > to the repo than is the case with public repositories like Maven
> > > > > > Central. I'm not sure it's actually possible to follow these
> steps
> > > > > > today, though perhaps that could be changed.
> > > > > >
> > > > > > I'd still like to see the code in the repo that implements
> support
> > >
> > > for
> > >
> > > > > > this or, better yet, a sample project that demonstrates
> relocation
> > > > > > is
> > > > > > possible.
> > > > > >
> > > > > > If this does work, I can see a lot of use cases for it, but I'm
> > > > > > currently working with the assumption it is not.
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Hervé BOUTEMY
In reply to this post by Jonathan Valliere
for people interested in working on this relocation topic:

1. I just updated the relocation guide to add some details gathered from the
current discussion [1]

2. I'll be at JChateau unconference [2] mid-march: if people want to join, we
could probably work on this topic

Regards,

Hervé

[1] https://maven.apache.org/guides/mini/guide-relocation.html

[2] https://www.jchateau.org/

Le jeudi 20 février 2020, 08:54:53 CET Hervé BOUTEMY a écrit :

> +1
>
> probably will start by improving the documentation, because this is really
> the current intent from what I can understand: a relocation pom only
> provides relocation info only, no jar, no build info
>
> like https://repo.maven.apache.org/maven2/ant/ant/1.7.0/ that points to
> https://repo.maven.apache.org/maven2/org/apache/ant/ant/1.7.0/
>
> AFAIK, there is no modification expected on existing artifacts, just
> relocation poms to create at old coordinates to point new coordinates = the
> new canonical coordinates
>
>
> then perhaps the way it is implemented can be improved: one issue I can see
> (from a pure theoretical point of view, I didn't take time to make extensive
> tests) is to define when you stop publishing relocation poms at old
> coordinates, ie. starting with which version?
> and how to be sure that the relocation is detected when resolving both old
> coordinates and new coordinates that are both canonical coordinates?
>
> for example ant:ant:1.6.5 (= canonical coordinates for this release) and
> org.apache.ant:ant:1.8.0 (= canonical coordinates for this release), given
> there is no relocation pom published for ant:ant:1.8.0, only for
> ant:ant:1.7.0
>
> Regards,
>
> Hervé
>
> Le mercredi 19 février 2020, 16:48:38 CET Jonathan Valliere a écrit :
> > Maybe we need to rework how this functionality works.  It should be
> > essentially a symlink with a warning message within the resolver so they
> > both resolve to the same artifact.
> >
> > On Wed, Feb 19, 2020 at 8:58 AM Anders Hammar <[hidden email]> wrote:
> > > In real practice it doesn't work well though, as someone already brought
> > > up. It can result in duplication of libraries on the class path (the
> > > same
> > > library under different groupId).
> > >
> > > /Anders (mobile)
> > >
> > > Den ons 19 feb. 2020 14:52Elliotte Rusty Harold <[hidden email]>
> > >
> > > skrev:
> > > > I set up some simple projects and tested this manually. As best I can
> > > > determine, relocation does work as one would hope, at least in Maven
> > > > and M2E. (No idea about Gradle or Ivy.)
> > > >
> > > > The documentation should probably be rewritten because it assumes you
> > > > can change published pom.xml files, which isn't true on Maven central.
> > > >
> > > > On Mon, Feb 17, 2020 at 3:36 PM Hervé BOUTEMY <[hidden email]>
> > > >
> > > > wrote:
> > > > > you can test with
> > > > > https://repo.maven.apache.org/maven2/ant/ant/1.7.0/ant-1.7.0.pom
> > >
> > > https://repo.maven.apache.org/maven2/javax/xml/jaxrpc/1.1/jaxrpc-1.1.pom
> > >
> > >
> > > https://repo.maven.apache.org/maven2/javax/xml/jaxb-api/1.0.1/jaxb-api-1
> > > .0
> > > .1.pom>
> > >
> > > > > testing relocation was on my todo list for years, but I never really
> > >
> > > test
> > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le dimanche 16 février 2020, 15:18:17 CET Elliotte Rusty Harold a
> > >
> > > écrit :
> > > > > > On Sun, Feb 16, 2020 at 2:35 AM <[hidden email]> wrote:
> > > > > > > see:
> > > > > > > -
> > >
> > > http://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_relocatio
> > > n
> > >
> > > > > > > - https://maven.apache.org/guides/mini/guide-relocation.html
> > > > > >
> > > > > > The guide to relocation seems to assume a lot more access and
> > > > > > control
> > > > > > to the repo than is the case with public repositories like Maven
> > > > > > Central. I'm not sure it's actually possible to follow these steps
> > > > > > today, though perhaps that could be changed.
> > > > > >
> > > > > > I'd still like to see the code in the repo that implements support
> > >
> > > for
> > >
> > > > > > this or, better yet, a sample project that demonstrates relocation
> > > > > > is
> > > > > > possible.
> > > > > >
> > > > > > If this does work, I can see a lot of use cases for it, but I'm
> > > > > > currently working with the assumption it is not.
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]