This message was deleted.

There's no such things as "maven central snapshots". Publication to Maven Central can come from several providers: OSSRH (the one you're referring to) but also directly from large organizations' own repository managers: https://central.sonatype.org/publish/large-orgs/#is-anybody-doing-this-already So if a method were added, it should rather be named

ossrhSnapshots

to begin with.

Not much, especially as newer users on OSSRH have not the old standard URL

@Vampire I was thinking of the function internally adding both s01 and the legacy URLs

And if projects provide snapshots, it's their duty to tell you where to find them (some won't publish to OSSRH snapshots but ask you to get them from other repositories: GitHub Maven repositories, or JitPack, etc.) so you shouldn't have to "hunt down the URL", or hunt it down for every dependency you want to use snapshots of.

both s01 and the legacy URLs

It is not

s01

for all newer ones, it can vary. And what Thomas said

Most projects I use typically just say something along the lines of "yes we have snapshots available". I always include that info in my libraries, but not everyone does. I haven't memorized the OSSRH URLs (and probably never will), so I have to context switch from whatever I'm building to go find the URLs to copy paste into the project. I also don't always remember the functions to call to only use the repository for snapshots. I have a convention plugin that does this, but it can't be used with the

pluginManagement

block, which is why I think it would be nice if it were part of Gradle. Using an init script seems like overkill for this, and isn't practical for me to use across many different environments that my projects are built in.

Central does not host snapshots, only releases.

I've usually seen the OSSRH repos colloquially referred to as maven central snapshots, but for the sake of correctness I'd be ok with the function being called

ossrhSnapshots

😅

As we said, there can be a multitude of urls, and many projects don't publish snapshots at all, or do not publish them to OSSRH. It is really up to each project to document how to get hold of snapshot builds exactly and if they don't, then this is a documentation bug you should report and get fixed by them. 🙂 Besides that, why should a convention settings plugin not be able to define

pluginManagement

repositories? The only case where this should not work is for settings plugins as for those it would be too late to configure it from a settings plugin naturally.

why should a convention settings plugin not be able to define pluginManagement repositories

Hmm I never thought about adding the repositories manually. My convention plugin exposes a

mavenCentralSnapshots

function but I can't use it in the

pluginManagement

block. But as you said that wouldn't help for settings plugin

Feel free to post a feature request to Gradle repo. But they did not even add

jitpack()

(thank god they didn't 🙂)

It's linked in the OP 😅

And yes, you have to context switch to look up the URL, same as to find where they deploy production snapshots. Not everyone publishes to Maven Central, even though it would be nice.

Would be so cool if sonatype could DNS map this stuff

Even then it would most probably not be added, just like

jitpack()

was not added. 🙂

baby steps 🙂

I think publishing snapshots to the sonatype snapshot repository is as standard as mavenCentral for most people. I would like to see that function added as

google()

. I don’t think it is necessary to add all urls, the base one fetch all s01 and so on, and if not, we should ask sonatype for this

> Btw. you don't really "need" mavenContent { snapshotsOnly() }, that's merely an optimization. > Doesn't that prevent the repo from being used to resolve non snapshot dependencies? That's a pretty big optimization to miss, especially in large projects

Even I am not a fan of jitpack and I had 0 projects with it and no plans to use in the future, if a lot of people uses it, I would add it too.

> Doesn't that prevent the repo from being used to resolve non snapshot dependencies? Yes, but there are no non-snapshot builds anyway. And if you put it after the production repos it will also never be asked for the non-snapshot builds found in the other repositories.

The main one for me is about security. That doesn’t apply to the snapshots repo one. About reproducible builds, I don’t think we should take that consideration, if so, we should drop using any programming language for the scripts as a simple

if

can do a build unreproducible

I think publishing snapshots to the sonatype snapshot repository is as standard as mavenCentral for most people.

As said (linked) above, Apache and JBoss/RedHat at least don't publish their snapshots to OSSRH. Others do publish to OSSRH but not in the common/shared repositories (e.g. Jetty, Plexus, Vaadin)

For sure, but most companies uses it. We could drop MavenCentral with that premise as Google uses its own repo for example.

Well, all discussion here is pretty moot, as Gradle folks already closed the request as "won't fix". 🙂

Changing that is just a button click away 😉

Not really, it is "convincing them" away and that is pretty far. 😄

Square is one of the larger companies around open source in Java and Android for example, and it uses it for all its projects. Most top Kotlin/Android open source projects I know use that repository.

The one in the OP here is for OSSRH snapshots

The reasoning for closing it was related to my suggestion for a

s01

parameter

Could you check if that s01 is necessary?

It is not only necessary, it can even vary

@Vampire was that sarcastic then 🙂 https://github.com/gradle/gradle/issues/16310#issuecomment-801084904

And I don't think it was only due to that parameter

That is annoying, this is the mine in my convention plugin, but maybe I am not using any dependency from the new URL.

public fun RepositoryHandler.sonatypeSnapshot(action: MavenArtifactRepository.() -> Unit = {}) {
    maven("<https://oss.sonatype.org/content/repositories/snapshots>", action)
}

@Vampire was that sarcastic then

Not really sarcasm. If JitPack would be added due to popularity, OSSRH snapshots should be considered too. Both are only really usable for snapshots.

Anyway, I think Sonatype should improve that as they should do exactly the same they do with

MavenCentral

Tell them 🙂

I asked in my Jira issue, to be honest, I don't know how to communicate with them as I am unable to create new issues in its Jira 😕

You should be able to create new issues on https://issues.sonatype.org/ for OSSRH project if you are logged in.