This message was deleted.

The experience is that you have to use the nexus publish plugin to avoid that: https://github.com/gradle-nexus/publish-plugin

There's also this one which is pretty good - https://github.com/vanniktech/gradle-maven-publish-plugin

@Eli Graber do you know the differences compared to

gradle-nexus.publish-plugin

Cédric mentioned? That is what I usually use and which always worked perfectly fine.

IIRC

gradle-nexus.publish-plugin

is more powerful, but

gradle-maven-publish-plugin

is more opinionated so it's easier to setup and get started with less involvement

Thanks, then I stay with more powerful. 🙂

There are A LOT of issues with Nexus publishing in Gradle 8 unfortunately, including some bugs in shading de[s. I ended up putting publishing to a convention plugin. If someone is interested, we could join powers and do somewhat official convention plugin that prepares artifacts, verifies them & publishes to central

I find the

maven-publish

experience to be really frustrating. That comes from both Gradle's side (it's buggy, not up to date with features like the Provider API or config cache, has really unfriendly error messages, and is generally janky) and from the Sonatype side (their Gradle docs are severely outdated, their processing and tooling is ancient and unfriendly, and they have weird requirements like a Javadoc jar even for non Java projects).

I've been using

gradle-maven-publish-plugin

for a while now with JVM and KMP projects and it works great across the board. One liner convention plugin, a couple of POM properties in gradle.properties and I never think about it again.

Thanks for all the replies! > Gradle still doesn't have the concept of "transactional publishing" Funny though, because the Nexus process is exactly the one where you do not necessarily need that. Because things go into staging first.... This would be much more needed for "simpler" repository implementations where things go directly to "production". > If someone is interested, we could join powers and do somewhat official convention plugin that prepares artifacts, verifies them & publishes to central Happy to help sharing a good (aka the officially right?) solution. But what is it as of now? What I want is something simple™️ (from a user perspective). • No "powerful" plugin that can do a hundred additional things that I don't need (but which causes problems) • Something that does not block me from using latest Gradle perf. features like the configuration cache • Something where everything I configure is the repo url and the credentials • The only "Nexus specific" feature I would like to have is a Gradle equivalent to

<autoReleaseAfterClose>true</autoReleaseAfterClose>

Can someone point me at such a solution? (not plugin docu pages, but a fully working example) Thanks!

To chuck another library in, I've considered adapting https://github.com/martinbonnin/vespene into a Gradle plugin, since it's written in Kotlin and it's so fast at uploading to Sonatype that it got some libraries banned. (cc @Martin)

Funny though, because the Nexus process is exactly the one where you do not necessarily need that. Because things go into staging first....

Yeah, well, it is not so much about transactional. The problem is with things being uploaded in parallel or from different IPs which often happened on CircleCI or Travis (don't remember which) landing in multiple staging repositories if you did not explicitly open one staging repository and are uploading explicitly into that staging repository.

But what is it as of now?

Imho that is the exactly the

gradle-nexus/publish-plugin

that Cédric and me mentioned. It is a merge of the old couple of

gradle-nexus-staging-plugin

and

nexus-publish-plugin

which also worked together before already. It has exactly the two purposes to fix the multi-staging repositories by creating one explicitly and uploading to it, and being able to finish the release by using a Gradle task without needing to open the Sonatype OSS web interface, nothing more fancy in it.

What I want is something simple™️ (from a user perspective).

Check, imo

• No "powerful" plugin that can do a hundred additional things that I don't need (but which causes problems)

Check

• Something that does not block me from using latest Gradle perf. features like the configuration cache

Half-check. Both plugins, the one I use since years and

gradle-maven-publish-plugin

cannot be fully CC compatible, as

maven-publish

itself is not fully CC compatible, so hopefully with Gradle 9

maven-publish

and both these plugins become fully CC compatible. But luckily you do not release to Maven Central that often, so CC should actually not be the biggest concern. At least

gradle-nexus/publish-plugin

(and I believe also the other) is not preventing you to use CC for all other task by using bad listeners or similar.

• Something where everything I configure is the repo url and the credentials

Check, it even has the right URLs for Maven Central built-in, unless you are a "new" user and need the "new" URL scheme which can vary by user.

• The only "Nexus specific" feature I would like to have is a Gradle equivalent to

<autoReleaseAfterClose>true</autoReleaseAfterClose>

Check, so to say, just use the task that does what you want, like

releaseSonatypeStagingRepository

Can someone point me at such a solution? (not plugin docu pages, but a fully working example)

Thanks!

A full example should be

nexusPublishing {
    repositories {
        sonatype {
            stagingProfileId = sonatypeStagingProfileId
            username = sonatypeUsername
            password = sonatypePassword
        }
    }
}

tasks.publish {
    val closeAndReleaseStagingRepository by tasks.existing
    dependsOn(closeAndReleaseStagingRepository)
}

where the profile id configuration is an optional performance tweak. The plugin will get it via API if it is not configured.

@Vampire I had a look at that plugin before but it had some jank so I couldn't use it, e.g. https://github.com/gradle-nexus/publish-plugin/issues/81. It's probably better than the Gradle maven-publish plugin, but it didn't work for me. The benefit would be that it has a Sonatype client, and at the moment Sonatype doesn't provide any documentation about their API (the last time I checked their advice was "just look how it works in the dev console in a browser and reverse engineer it"!!)

Thanks @Vampire for the detailed response!

The publishing infrastructure for Mockito regularly runs into this issue and I have to contact Sonatype to cleanup the problematic staging repositories and rerun the tags. We use Shipkit for this (https://github.com/shipkit/shipkit-auto-version) which was originally part of Mockito build infrastructure and internally it uses

maven-publish

Why do you have to contact Sonatype? Is it no longer possible to delete those staging repositories on your own? Previously this was possible.

I think Vespene is around the same speed as the default Gradle upload. The main difference is it comes with a script to batch upload which can got you rate limited. I used that to transfer some older libs from jcenter to Sonatype. (kudos to the Sonatype team though, they've been quite fast as unlocking anyone impacted).