Re: Maven GroupID authority

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

Re: Maven GroupID authority

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

Jonathan Valliere
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 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.

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.

On Fri, Feb 14, 2020 at 8:11 AM Elliotte Rusty Harold <[hidden email]>
wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

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

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

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

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

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

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