maven-public proxies Maven Central - documented or intended behavior?

[A248]

Expected behavior

As far as I can tell, this repository did not used to proxy Maven Central. Perhaps this changed recently in relation to PaperMC's switch to JFrog Artifactory Israeli software. I don't know.

If this is intended, I would expect it to be documented. The repository is recommended for all starting plugin developers, and taking over Maven dependency resolution for central artifacts is surely unexpected behavior.

If it is not intended, well, you could save a lot of bandwith and resource usage by not proxying Maven Central. Some of my project's builds are failing with corrupted central artifacts, maybe because your repository is not handling the load, though I am unsure.

Observed/Actual behavior

The maven-public repository path proxies Maven Central. For example, take the following jar. It is resolved by the PaperMC repository instance, despite being an artifact located on Maven Central.

https://repo.papermc.io/repository/maven-public/org/slf4j/slf4j-api/1.2/slf4j-api-1.2.jar

I purposefully picked an older version of slf4j to demonstrate that all central artifacts are proxied, even though which don't have a useful relation to PaperMC.

Steps/models to reproduce

Visit a Maven-formatted central artifact URL through the maven-public PaperMC repository.

Plugin and Datapack List

N/A

Paper version

N/A

Other

I should note that maven-releases and maven-snapshots are not proxied. This makes sense. Also, they are more likely to return HTTP 302 redirects when resolving artifacts, and I think this happens because the artifacts are uncached.

In my testing, some artifacts resolve immediately with 200 status code:

• https://repo.papermc.io/repository/maven-public/org/ow2/asm/asm/9.0/asm-9.0.jar
• https://repo.papermc.io/repository/maven-public/com/destroystokyo/paper/paper-api/1.16.5-R0.1-SNAPSHOT/paper-api-1.16.5-R0.1-20211218.082619-371.jar

While others generated 302's to artifactory URLs:

• https://repo.papermc.io/repository/maven-public/org/slf4j/slf4j-api/1.2/slf4j-api-1.2.jar -> https://artifactory.papermc.io/ui/native/universe/org/slf4j/slf4j-api/1.2/slf4j-api-1.2.jar
• https://repo.papermc.io/repository/maven-snapshots/com/destroystokyo/paper/paper-api/1.16.5-R0.1-SNAPSHOT/paper-api-1.16.5-R0.1-20211218.082619-371.jar (note maven-snapshots)

[masmc05]

It's a good practice to cache stuff in own repositories so stuff like CI can be faster and more reliable, including paper's CI of building and publishing paper builds, api and dev bundle. This is also true for a majority of other repositories I've seen, that's why it's recommended https://docs.gradle.org/current/userguide/best_practices_dependencies.html#use_content_filtering

[A248]

Appreciate the comment but this is not what I opened the issue for.

[kashike]

Yes, this is intended behavior and predates our move to Artifactory by many years.