Re: Maven GroupID authority

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

Re: Maven GroupID authority

Manfred Moser-4
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

Manfred Moser-4
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 there is a feature in Maven that allows migration and such but it is barely used.

Manfred

Jonathan Valliere wrote on 2020-02-13 19:28 (GMT -08:00):

> 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]
>>
>>
>

---------------------------------------------------------------------
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
In reply to this post by Manfred Moser-4
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 referenced problem, of having multiple versions of
the same dependency in the same classpath, is only going to become
impossible with Java Modules.

 Maven is at an optimal position within the community to prevent module
naming from going haywire and becoming useless.  I believe these two issues
are intrinsically linked.

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

> 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

Hervé BOUTEMY
In reply to this post by Manfred Moser-4
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.

Regards,

Hervé

Le vendredi 14 février 2020, 04:23:15 CET Manfred Moser a écrit :

> 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]





---------------------------------------------------------------------
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

Hervé BOUTEMY
In reply to this post by Manfred Moser-4
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 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. In Java 9+ compiles the breakage would
> early. immediate, and complete though still hard to debug and work
> around. In Java 8-, the breakage could be subtle and unnoticed. See
> https://jlbp.dev/JLBP-6.html for more details.
>
> There are efforts underway to improve the provenance and vouching of
> open source artifacts to avoid issues like the ones that affected NPM:
> https://www.csoonline.com/article/3324599/hacker-adds-malicious-bitcoin-stea
> ling-code-to-popular-javascript-library.html
>
> However in many ways Maven is already ahead of the curve here, and
> much better than it was 15 years ago. I'm not sure enforcing group IDs
> as domain names, even if we could do that, would materially improve
> our security posture.
+1


>
> On Thu, Feb 13, 2020 at 10:28 PM Jonathan Valliere
>
> <[hidden email]> 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]>
> >
> > 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]





---------------------------------------------------------------------
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

Tamás Cservenák
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 at 12:03 AM Manfred Moser <[hidden email]>
wrote:

> 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 <[hidden email]>
> 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 AFAIK, it is under-tested...
> >>
> >
> > Interesting. How does that affect dependency mediation? That is, if an
> > old artifact (pre relocation) and a newer artifact both appear in the
> > dependency graph will both be added to the classpath? Or does Maven
> > treat them as the same and pick the one it sees first?
> >
> >
> >
> > --
> > 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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Hervé BOUTEMY
In reply to this post by Manfred Moser-4
see:
- http://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_relocation
- https://maven.apache.org/guides/mini/guide-relocation.html

Everything is there.
I confess I never tried it myself, but there are POMs in central using it.

----- Mail original -----
De: "Elliotte Rusty Harold" <[hidden email]>
À: "Maven Developers List" <[hidden email]>
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
<[hidden email]> 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 don't think Maven works like that, but feel free to point me
to the code in Github that proves me wrong.

--
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]

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Sander Verhagen
Having just read through the "Guide to relocation", and having never consciously encountered this in the wild (I'm not a big name in this community, but I have used Maven extensively for many years), this seems to be a solution to direct users to a new groupId when they are upgrading to a new version. It might not be a solution at all to help with dependency resolution (when two conflicting versions of essentially the same artifacts are brought on the classpath because they no longer have matching coordinates). Perhaps someone could elaborate who understands the relocation mechanism better?



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

On 15/02/2020 23.35, [hidden email]<mailto:[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

Everything is there.
I confess I never tried it myself, but there are POMs in central using it.

----- Mail original -----
De: "Elliotte Rusty Harold" <[hidden email]><mailto:[hidden email]>
?: "Maven Developers List" <[hidden email]><mailto:[hidden email]>
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
<[hidden email]><mailto:[hidden email]> 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 don't think Maven works like that, but feel free to point me
to the code in Github that proves me wrong.



Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Elliotte Rusty Harold
In reply to this post by Hervé BOUTEMY
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]