JBang using non canonical id for maven central

[davsclaus]

When using plain vanilla Apache Maven then it download JARs into local disk (.m2/repository)

For example from Apache Camel when having an empty m2 repository, and I build and run an example from the Camel 3.20.4 release

Then I have metadata such as

~/.m2/repository/org/apache/camel/camel-core-engine/3.20.4 ❯ cat _remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Wed Jul 05 10:51:24 CEST 2023
camel-core-engine-3.20.4.jar>central=
camel-core-engine-3.20.4.pom>central=

However if I use jbang, then it appears that is uses mavencentral as the repo id, which leads to duplicated tracked files by Maven (using Camel 4.0.0-RC1 with jbang and camel):

~/.m2/repository/org/apache/camel/camel-core-engine/4.0.0-RC1 ❯ cat _remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Wed Jul 05 10:48:25 CEST 2023
camel-core-engine-4.0.0-RC1.pom>central=
camel-core-engine-4.0.0-RC1.jar>mavencentral=
camel-core-engine-4.0.0-RC1.jar>central=
camel-core-engine-4.0.0-RC1.pom>mavencentral=

We run jbang in Camel with a script file that has these DEPS listed

//JAVA 11+
//REPOS mavencentral,apache-snapshot=http://repository.apache.org/content/groups/snapshots/
//DEPS org.apache.camel:camel-bom:${camel.jbang.version:3.20.6}@pom
//DEPS org.apache.camel:camel-jbang-core:${camel.jbang.version:3.20.6}
//DEPS org.apache.camel.kamelets:camel-kamelets:${camel-kamelets.version:3.20.6}

Notice that REPOS we use the jbang standard way with mavencentral.

So this leads me into thinking that JBang is using mavencetral as the repo id for its downloader. And vanilla standard Maven uses central.

All together this leads to ugly INFO spam logging from Maven now

2023-07-05 10:31:43.296 INFO 9147 — [- MavenDownload] ternal.impl.DefaultArtifactResolver : Artifact org.apache.camel:camel-tooling-model:pom:3.21.0 is present in the local repository, but cached from a remote repository ID that is unavailable in current build context, verifying that is downloadable from [central (https://repo1.maven.org/maven2, default, releases)]
2023-07-05 10:31:43.296 INFO 9147 — [- MavenDownload] ternal.impl.DefaultArtifactResolver : Artifact org.apache.camel:camel-tooling-model:pom:3.21.0 is present in the local repository, but cached from a remote repository ID that is unavailable in current build context, verifying that is downloadable from [central (https://repo1.maven.org/maven2, default, releases)]
2023-07-05 10:31:43.334 INFO 9147 — [- MavenDownload] ternal.impl.DefaultArtifactResolver : Artifact org.apache.camel:camel-tooling-model:jar:3.21.0 is present in the local repository, but cached from a remote repository ID that is unavailable in current build context, verifying that is downloadable from [central (https://repo1.maven.org/maven2, default, releases)]
2023-07-05 10:31:43.335 INFO 9147 — [- MavenDownload] ternal.impl.DefaultArtifactResolver : Artifact org.apache.camel:camel-tooling-model:jar:3.21.0 is present in the local repository, but cached from a remote repository ID that is unavailable in current build context, verifying that is downloadable from [central (https://repo1.maven.org/maven2, default, releases)]

More details at:
https://issues.apache.org/jira/browse/CAMEL-19577

[davsclaus]

Okay we fixed this in camel-jbang to use

//REPOS central=https://repo1.maven.org/maven2,apache-snapshot=http://repository.apache.org/content/groups/snapshots/

Instead of

//REPOS mavencentral,apache-snapshot=http://repository.apache.org/content/groups/snapshots/

[maxandersen]

Interesting - seems like we should add central as shortcut and make that default to play nice with defaults.

[quintesse]

Yeah, seems like a good idea.
I never even knew that those IDs were actually used for something.

[davsclaus]

I created a ticket: #1649