You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jonathan Valliere <jo...@emoten.com> on 2020/02/14 01:06:42 UTC
Maven GroupID authority
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
Re: Maven GroupID authority
Posted by Christian Stein <so...@gmail.com>.
On Fri, Feb 14, 2020 at 8:11 AM Hervé BOUTEMY <he...@free.fr> 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
Re: Maven GroupID authority
Posted by Hervé BOUTEMY <he...@free.fr>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <so...@gmail.com> wrote:
> On Fri, Feb 14, 2020 at 6:37 AM Manfred Moser <ma...@simpligility.com>
> 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
>
Re: Maven GroupID authority
Posted by Christian Stein <so...@gmail.com>.
On Fri, Feb 14, 2020 at 6:37 AM Manfred Moser <ma...@simpligility.com>
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
Re: Maven GroupID authority
Posted by Manfred Moser <ma...@simpligility.com>.
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.
With binary repositories all over the place that have very little to no enforcement what happens in Maven Central can at best be a good example. At worst a system that everyone avoids..
Things like github binaries, dockerhub, npmjs, bintray and many others have very little to no guidance or enforcement ...
The burden lies with the user not to be cheated.
Manfred
PS: and the cynic in me says that there are plenty of "open source security" companies out there that want to "help" you and provide tooling to organize the mess, so they of course have very little to no interest to have clear ownership and rules in repositories... Maven Central is really the only place with some real rules.
Jonathan Valliere wrote on 2020-02-13 20:28 (GMT -08:00):
> 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 <ma...@simpligility.com>
> 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
>> > [ sander@sanderverhagen.net<ma...@sanderverhagen.net> ]
>> >
>> > 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
>> > <ma...@simpligility.com>
>> > 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:
>> > dev-unsubscribe@maven.apache.org<mailto:dev-unsubscribe@maven.apache.org
>> >
>> > For additional commands, e-mail:
>> > dev-help@maven.apache.org<ma...@maven.apache.org>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <ma...@simpligility.com>
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
> > [ sander@sanderverhagen.net<ma...@sanderverhagen.net> ]
> >
> > 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
> > <ma...@simpligility.com>
> > 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:
> > dev-unsubscribe@maven.apache.org<mailto:dev-unsubscribe@maven.apache.org
> >
> > For additional commands, e-mail:
> > dev-help@maven.apache.org<ma...@maven.apache.org>
> >
> >
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven GroupID authority
Posted by Manfred Moser <ma...@simpligility.com>.
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
> [ sander@sanderverhagen.net<ma...@sanderverhagen.net> ]
>
> 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
> <ma...@simpligility.com>
> 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:
> dev-unsubscribe@maven.apache.org<ma...@maven.apache.org>
> For additional commands, e-mail:
> dev-help@maven.apache.org<ma...@maven.apache.org>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Sander Verhagen <sa...@sanderverhagen.net>.
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
[ sander@sanderverhagen.net<ma...@sanderverhagen.net> ]
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 <ma...@simpligility.com>
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: dev-unsubscribe@maven.apache.org<ma...@maven.apache.org>
For additional commands, e-mail: dev-help@maven.apache.org<ma...@maven.apache.org>
Re: Maven GroupID authority
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ma...@simpligility.com>
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 <he...@free.fr>
> 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
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven GroupID authority
Posted by Manfred Moser <ma...@simpligility.com>.
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 <he...@free.fr> 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
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Fri, Feb 14, 2020 at 5:12 PM Hervé BOUTEMY <he...@free.fr> 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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Hervé BOUTEMY <he...@free.fr>.
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
>
> <jo...@emoten.com> 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 <ma...@simpligility.com>
> >
> > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
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 <he...@free.fr> wrote:
>
> 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 <an...@hammar.net> 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 <el...@ibiblio.org>
> > > >
> > > > 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 <he...@free.fr>
> > > > >
> > > > > 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <an...@hammar.net> 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 <el...@ibiblio.org>
> > >
> > > 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 <he...@free.fr>
> > > >
> > > > 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Manfred Moser <ma...@simpligility.com>.
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 <he...@free.fr> 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 <an...@hammar.net> 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 <el...@ibiblio.org>
>> > >
>> > > 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 <herve.boutemy@free.fr
>> >
>> > > >
>> > > > 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
>> > > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > >
>> > > > --
>> > > > Elliotte Rusty Harold
>> > > > elharo@ibiblio.org
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <he...@free.fr> 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 <an...@hammar.net> 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 <el...@ibiblio.org>
> > >
> > > 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 <herve.boutemy@free.fr
> >
> > > >
> > > > 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
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.
Re: Maven GroupID authority
Posted by Hervé BOUTEMY <he...@free.fr>.
+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 <an...@hammar.net> 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 <el...@ibiblio.org>
> >
> > 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 <he...@free.fr>
> > >
> > > 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <an...@hammar.net> 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 <el...@ibiblio.org>
> 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 <he...@free.fr>
> > 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
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.
Re: Maven GroupID authority
Posted by Anders Hammar <an...@hammar.net>.
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 <el...@ibiblio.org> 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 <he...@free.fr>
> 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven GroupID authority
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
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 <he...@free.fr> 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sun, Feb 16, 2020 at 2:35 AM <he...@free.fr> 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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Sander Verhagen <sa...@sanderverhagen.net>.
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
[ sander@sanderverhagen.net<ma...@sanderverhagen.net> ]
On 15/02/2020 23.35, herve.boutemy@free.fr<ma...@free.fr> 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" <el...@ibiblio.org>
?: "Maven Developers List" <de...@maven.apache.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
<jo...@emoten.com> 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.
Re: Maven GroupID authority
Posted by he...@free.fr.
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" <el...@ibiblio.org>
À: "Maven Developers List" <de...@maven.apache.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
<jo...@emoten.com> 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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sat, Feb 15, 2020 at 1:29 PM Jonathan Valliere
<jo...@emoten.com> 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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <el...@ibiblio.org>
wrote:
> On Sat, Feb 15, 2020 at 10:55 AM Jonathan Valliere
> <jo...@emoten.com> 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
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
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.
Re: Maven GroupID authority
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sat, Feb 15, 2020 at 10:55 AM Jonathan Valliere
<jo...@emoten.com> 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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <el...@ibiblio.org>
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
> <jo...@emoten.com> 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 <manfred@simpligility.com
> >
> > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
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.
Re: Maven GroupID authority
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
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
<jo...@emoten.com> 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 <ma...@simpligility.com>
> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Manfred Moser <ma...@simpligility.com>.
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 <ma...@simpligility.com>
> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <ma...@simpligility.com>
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven GroupID authority
Posted by Manfred Moser <ma...@simpligility.com>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven GroupID authority
Posted by Robert Scholte <rf...@apache.org>.
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 <jo...@emoten.com> 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