SNAPSHOTS are missing maven-metadata.xml file

[StefMa]

Expected and Results

I published a library to the snapshot repo.

But if I try to download/use it, it fails with:

Checking the SNAPSHOT repo reveals there is no maven-metadata and no POM file at all (not sure if POM is required).
See https://central.sonatype.com/service/rest/repository/browse/maven-snapshots/com/ioki/result/

This is an KMP project.
You can check the current code here:
ioki-mobility/Result#17
I published on my local machine.

Related environment and versions

No response

Reproduction steps

No response

Anything else?

No response

[martinbonnin]

mmm that rings a bell. We had to exclude maven-metadata for releases to work. Looks like that is still required for snapshots. I'll dig

[StefMa]

Hmm.. I'm not sure if this is so easy 🤔
Seems the maven-metadata files get somehow merged (with the updated version).

In the old world (using OSSHR), the maven-metadata file on a KMP project with multiple snapshot versions located at group/project-jvm/0.8.0-SNAPSHOT/maven-metadata.xml, were updated each time a new SNAPSHOT version was pushed. It always pointed to the latest version of the SNAPSHOT.

Also, the top-level maven-metadata file were updated, located at group/project-jvm/maven-metadata.xml.
It looked like this:

<metadata>
<groupId>group</groupId>
<artifactId>project-jvm</artifactId>
<versioning>
<latest>0.8.0-SNAPSHOT</latest>
<release/>
<versions>
<version>0.0.1-SNAPSHOT</version>
<version>0.6.0-SNAPSHOT</version>
<version>0.7.0-SNAPSHOT</version>
<version>0.8.0-SNAPSHOT</version>
</versions>
<lastUpdated>20250511175111</lastUpdated>
</versioning>
</metadata>

If I check my local build, it do look like this merging stuff were done by the maven-publish plugin and not by the maven central server.

The first behaviour differs from a release.
There is no maven-metadata inside a version itself (so this doesn't exist! group/project-jvm/0.8.0-SNAPSHOT/maven-metadata.xml). But the latter is similar. There is also such a file:

<metadata>
<groupId>group</groupId>
<artifactId>project</artifactId>
<versioning>
<latest>0.8.0</latest>
<release>0.8.0</release>
<versions>
<version>0.1.0</version>
<version>0.2.0</version>
<version>0.3.0</version>
<version>0.4.0</version>
<version>0.5.0</version>
<version>0.6.0</version>
<version>0.7.0</version>
<version>0.8.0</version>
</versions>
<lastUpdated>20250513133607</lastUpdated>
</versioning>
</metadata>

[marcphilipp]

I've just tried the support for publishing snapshots and also noticed that the maven-metadata.xml file wasn't updated. Moreover, it restart the counter at 1. Is uploading files with names containing SNAPSHOT not supported so the plugin has to create the timestamp?

[martinbonnin]

Yea, I'm not clear who is responsible for creating the timestamp and maven-metadata.xml file. Sounds like it should be handled remotely? I'll dig into what maven-publish is doing, see if we can replicated the behaviour

[martinbonnin]

Alright, it's a lot more involved than what I thought. Reading from the Gradle maven-publish implementation, the steps are:

• Download the existing maven-metadata.xml from the repo
• Get the next version number
• Patch all the files with the new timestamped name
• Compute the new maven-metadata.xml file
• Upload everything

I'll just reuse the existing implementation for the time being, will revisit later.

[martinbonnin]

Tentative workaround there. I'm conceptually not super happy with it because:

• It adds one more repository
• I haven't found a way to register the credentials lazily (see Feature Request: Property based implementation PasswordCredentials gradle/gradle#6943) so the repository is created in a good old afterEvaluate {} block
• Because it relies on the maven-publish plugin, it breaks the aggregation use case and now the credentials need to be configured in each subproject in addition of the aggregating one...

But it should be working as a band aid for now. The task is publishAllPublicationsToCentralSnapshots

[StefMa]

Not sure if this helps (or if this even work), but you can already register the repository, but configure the credentials later:

afterEvaluate {
    (publishing.repositories.findByName("nmcpCentralSnapshotsRepoName") as? MavenArtifactRepository)?.credentials {
        username = centralPortalOptions.username.get()
        password = centralPortalOptions.password.get()
    } ?: error("Something went wrong")
}

[StefMa]

The PR fixes the Snapshot implementation as it "just" uses maven-publish under the hood.
But the maven-metadata is still not updated for "real" releases.
Because those should also be updated to point to the latest release version, right?

[marcphilipp]

But the maven-metadata is still not updated for "real" releases.

That's the responsibility of the Portal, though, isn't it?

@StefMa When did you last try? I have been in contact with Sonatype support and they said there was a bug with maven-metadata.xml which they resolved last Friday (May 9).

[marcphilipp]

FWIW, I think defining the snapshots repo manually using the same credentials for maven-publish is simpler:

nmcp {
	centralPortal {
		username = providers.gradleProperty("mavenCentralUsername")
		password = providers.gradleProperty("mavenCentralPassword")
	}
}

repositories {
	maven {
		name = "mavenCentralSnapshots"
		url = uri("https://central.sonatype.com/repository/maven-snapshots/")
		credentials {
			username = providers.gradleProperty("mavenCentralUsername").orNull
			password = providers.gradleProperty("mavenCentralPassword").orNull
		}
	}
}

[martinbonnin]

But the maven-metadata is still not updated for "real" releases.

That's the responsibility of the Portal, though, isn't it?

That is my understanding as well, the publishing flows are wildly different.

FWIW, I think defining the snapshots repo manually using the same credentials for maven-publish is simpler

Agreed. #78 is basically doing just that so it adds zero value... With KotlinConf around the corner, I won't have time to dive into this but I'll rework this in a couple of weeks. Ultimately, I'd like nmcp to not rely on maven-publish at all and use the SoftwareComponents directly.

[StefMa]

I'm not sure who is repsonsive for this 🤷
I also haven't tested it yet "on production".

But when I publishToMavenLocal with different versions, I do see that the maven-publish plugin is creating the "top-level" maven-metadata-local.xml. The file contains all the versioning information.

Or if I define my own repository and publish:

publishing {
    repositories {
        maven(rootProject.layout.buildDirectory.dir("localMaven")) {
            name = "fakeLocal"
        }
    }
}

... then the maven-metadata.xml is generated by Gradle (maven-publish), and not the server...