FYI, this appears to be a case where Maven does not follow relocations
seamlessly:
https://issues.apache.org/jira/projects/MASSEMBLY/issues/MASSEMBLY-923
On Sat, Feb 22, 2020 at 4:33 AM Hervé BOUTEMY wrote:
>
> for people interested in working on this relocation topic:
>
> 1. I just updated the
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]
Anything that goes to Central is immutable .. so no edits or updates or
whatever. Make sure you keep that in mind
Manfred
Jonathan Valliere wrote on 2020-02-20 09:50 (GMT -08:00):
> Just indicate a date in the pom at which point the relocation warning turns
> into a relocation error. date.
Just indicate a date in the pom at which point the relocation warning turns
into a relocation error. 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é
+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
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 wrote:
> In real practice it doesn't work well though, as someone already
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 skrev:
> I set up some simple projects and
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
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
On Sun, Feb 16, 2020 at 2:35 AM 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
.org>
Envoy?: Samedi 15 F?vrier 2020 19:35:09
Objet: Re: Maven GroupID authority
On Sat, Feb 15, 2020 at 1:29 PM Jonathan Valliere
<mailto:jon.valli...@emoten.com> wrote:
If Central indicated a redirect/reallocation then there would never be the
duplicate classpath problem because
d"
À: "Maven Developers List"
Envoyé: Samedi 15 Février 2020 19:35:09
Objet: Re: Maven GroupID authority
On Sat, Feb 15, 2020 at 1:29 PM Jonathan Valliere
wrote:
>
> If Central indicated a redirect/reallocation then there would never be the
> duplicate classpath proble
On Sat, Feb 15, 2020 at 1:29 PM Jonathan Valliere
wrote:
>
> 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.
>
I really
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
wrote:
> On Sat, Feb
On Sat, Feb 15, 2020 at 10:55 AM Jonathan Valliere
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
How would changing the GroupID cause diamond dependencies? The builds
would just fail everywhere until the GroupID is updated in the pom files.
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
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
There are traces of it in resolver provider:
https://github.com/apache/maven/blob/716cc1fe02661897232a7cc3e4c1bb3b3df3b832/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L316
And AFAIK, it _does_ obeys it...
T
On Sat, Feb 15, 2020
>From what I know it is no taken into account by the resolver.
Elliotte Rusty Harold wrote on 2020-02-14 14:25 (GMT -08:00):
> On Fri, Feb 14, 2020 at 5:12 PM Hervé BOUTEMY wrote:
>>
>> Le vendredi 14 février 2020, 14:11:07 CET Elliotte Rusty Harold a écrit :
>> > Changing group IDs of
On Fri, Feb 14, 2020 at 5:12 PM Hervé BOUTEMY wrote:
>
> Le vendredi 14 février 2020, 14:11:07 CET Elliotte Rusty Harold a écrit :
> > Changing group IDs of existing projects is a very bad idea.
> there is relocation strategy:
> https://maven.apache.org/guides/mini/guide-relocation.html
> but
Le vendredi 14 février 2020, 14:11:07 CET Elliotte Rusty Harold a écrit :
> Changing group IDs of existing projects is a very bad idea.
there is relocation strategy:
https://maven.apache.org/guides/mini/guide-relocation.html
but AFAIK, it is under-tested...
> Not only
> does this break too many
Christian,
Those references are amazing and prove my point about the need to improve
the process to prevent imposters and other types of name collisions.
On Fri, Feb 14, 2020 at 1:35 AM Christian Stein wrote:
> On Fri, Feb 14, 2020 at 6:37 AM Manfred Moser
> wrote:
>
> > From the very start
Changing group IDs of existing projects is a very bad idea. Not only
does this break too many projects to count that are in production
today. It also introduces diamond dependencies and weird classpath
issues into projects because the same classes can now be pulled in
from multiple artifact jars.
On Fri, Feb 14, 2020 at 8:11 AM Hervé BOUTEMY 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
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
On Fri, Feb 14, 2020 at 6:37 AM Manfred Moser
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
>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
Java modules is going to compound this problem we already have. If
projects can't get on board with correctly structuring their
GroupID/Artifacts then why would they use good naming conventions for the
Modules? Without good naming conventions, the risk of collisions
increases. Manfred's
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
>
Ownership of established GAVs and assignment of new ones is all managed by
Sonatype as part of the onboarding to OSSRH.
>From all I know there is no policy for changes.. its entirely up to the
>projects.
Maybe Brian or Joel or someone else who is still with Sonatype can chime in.
Also.. fyi
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,
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
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
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
34 matches
Mail list logo
