This message was deleted.

github packages is what you are looking for

https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-gradle-registry although I think their documentation is bad, the conventional way to handle it in Gradle would be

maven(url = "<https://maven.pkg.github.com/USER/REPO/>") {
    name = "GitHubPackages"
    credentials(PasswordCredentials::class)
}

and

env:
  ORG_GRADLE_PROJECT_GitHubPackagesUsername: ${{ github.actor }}
  ORG_GRADLE_PROJECT_GitHubPackagesPassword: ${{ secrets.GITHUB_TOKEN }}

in your workflows

Hmm, is there an alternative? - a popular public maven repo to upload artefacts and access them without credentials?

nothing special about a maven repo, any static HTTP host will work (although Gradle requires it to support the HEAD method, so GitHub pages won't work)

sonatype snapshots repository or maven central repository using alpha, beta and so on

Please don't post alphas and betas to Maven Central. Maven Central should imho only be used for real releases, not snapshot or preview builds. For that, there is the Sonatype snapshots repository that you also have access to when having access to publish to Maven Central.

you can’t publish alphas or betas to snapshots repository as it only accept -snapshot versions

Oh, right. 😕

I think it is common to publish those versions on maven central tho, for example kotlin ones are there

they upload dev releases to their own https://maven.pkg.jetbrains.space/kotlin/p/kotlin/dev/

I think it is common to publish those versions on maven central tho, for example kotlin ones are there

That some projects do it, does not mean I need to like it. 😄 That always requires to then again filter them out from things like

gradle-versions

plugin,

refreshVersions

, dependabot, renovate bot, ...

@ephemient I was referring to alpha, beta and rc

This is the main reason why I am asking - I preffer not to upload alpha/beta/snapshoot

but for snapshot you have the snapshots repository

sonatype has staging repos. I think creating a maven central account also gives you one

you want to avoid to renovate use the snapshot versions? If you keep a stable version on the remote, renovate will not update it to snapshot even if it is higher

Yeah, but it had to get special logic to not use such versions. And this logic is usually also driven by version string matching which might or might not be correct, ... If Maven Central just had production versions, everything could just use it. 🙂

I mean, renovate avoids using any non final version by default, except if you are using a non stable version, and a version which is higher but has the same major, minor and path is released Supposing you are using 1.0.0-alpha.1 • release 1.0.0-alpha.2 would be updated by renovate • release 1.0.1-alpha.1 wouldn't be updated by renovate • release any final version would be updated by renovate Supposing you are using final version, 1.0.0 • release 1.0.1-alpha.1 wouldn't be updated by renovate • release any final version would be updated by renovate

Yes, I know and understood. Now try to read again what I said. They had to code that explicitly instead of just being able to use everything that is available in Maven Central. And other tools like

gradle-versions

plugin you have to configure accordingly.

I don't know what you mean with "had to code" 🤔

team

I guess he means that because there is a lot of non-release versions in maven renovate team had to figure this flow out implement custom logic to handle all of that. If maven would contain only release artefacts then this implementation would be much simpler.

Just imagine everyone would actually use semantic versioning, that would be a dream.