Not sure if anyone faces this, but for folks who publish SDKs to an internal repository using Gradle's maven-publish plugin: When I publish multiple modules with variants from a relatively large repo (~50 artifacts), some publications occasionally fail due to network issues. This causes the entire Gradle task to fail. Rerunning the publish task doesn't work since it retries all variants, and our repository rejects duplicate uploads for the same version. Current options I'm considering: 1. Delete the partial publish and republish everything (current approach) 2. Check what's already published and only publish remaining artifacts 3. Configure automatic retries within the maven-publish plugin (not sure how to implement this) 4. Use Gradle's --continue flag to skip failures Has anyone found better solutions or know how to implement option 3? Any alternative approaches?

I think 2 and 4 are problematic, because there are multiple files uploaded, what if 3 of 4 files were uploaded but the 4th is missing? Both approaches would probably eventually leave the broken publish present.

Yes 😕. I'm unable to come up with a simple enough solution for this. I feel 3 would be ideal if I could figure out how to. I'm not sure if this is a common problem either. That makes me wonder if I'm "holding it wrong"

On MavenCentral, the normal approach is to upload all the publications as one ZIP, then let Sonatype do the rest. Obviously this is not going to work for you directly, but depending on how your Maven repo is setup, it might work for you. Just leaving it there as an idea.

Another possibility could be to always upload the

.pom

last after all other files belonging to that artifact are successfully uploaded (and not upload it if they are not, or if it's uncertain). This way if the

.pom

is present you already know that this single artifact is complete and can be skipped. Otherwise you just retry that artifact, or delete+retry it depending on what works for your repo.

Thanks for the ideas 🙂. 1. I will check if it would be possible to upload as zip and have Sonatype handle the rest . (we use sonatype for our internal maven so it may be the case) 2. On uploading the pom last, unfortunately I'm not in control of the upload order, this is currently being done by the maven-publish plugin. Is there no way for me set up something custom for the network handler that maven-publish uses? side issue: gradle's handling of network requests has always been fragile?. Something similar occurs while trying to fetch artifacts from flaky repositories (like erstwhile jcenter). I wish there was a way to customize this behaviour.

Is there no way for me set up something custom for the network handler that maven-publish uses?

Nothing I'm aware of, besides using a custom Gradle distribution.

I wish there was a way to customize this behaviour.

Feel free to open a feature request or a PR that adds it. :-)

Well a variant of it was opened and they mentioned that this is intended behaviour 🙂 https://github.com/gradle/gradle/issues/12108

It surely is intended that the build fails if a dependency cannot be resolved. That does not mean that a retry would not make sense if there is none, or that customizing the network handler would not make sense. 🤷‍♂️

I agree with @Vampire. The workaround always has been to place the flaky repositories at the end of the list of repositories, especially for the case where a dependency can be resolved from more than one.

Or use repository content filters to control what is resolved from where

Sure, that makes sense. I'll create a FR for this soon then.