Gradle platform maven publish/resolution

Help/Discuss
1

Hi,

I have a project that defines a gradle platform that I publish on GitHub Packages using default configuration.

plugins {
    `java-platform`
    `maven-publish`
}

publishing {
    publications {
        create<MavenPublication>("myPlatform") {
            from(components["javaPlatform"])
        }
    }

    repositories {
        maven {
            name = "GitHubPackages"
            url = uri("https://maven.pkg.github.com/user/repo")
            credentials {
                username = project.findProperty("gpr.user") as String? ?: System.getenv("GITHUB_USERNAME")
                password = project.findProperty("gpr.key") as String? ?: System.getenv("GITHUB_TOKEN")
            }
        }
    }
}

This creates a

  • maven-metadata.xml file
  • xxx-1.2.12-20210410.072648-1.module file
  • xxx-1.2.12-20210410.072648-1.pom file

However since yesterday the build of my project that depends on this artifact fails with the following errors:
dependencies {
implementation(platform(“aaa:xxx:1.2.12-SNAPSHOT”))
}

> Could not find aaa:xxx:1.2.12-SNAPSHOT.
Searched in the following locations:
- https://jcenter.bintray.com/aaa/1.2.12-SNAPSHOT/maven-metadata.xml
- https://jcenter.bintray.com/aaa/1.2.12-SNAPSHOT/xxx-1.2.12-SNAPSHOT.pom
- https://maven.pkg.github.com/aaa/1.2.12-SNAPSHOT/maven-metadata.xml
- https://maven.pkg.github.com/aaa/1.2.12-SNAPSHOT/xxx-1.2.12-20210410.072648-1.module.pom

I don’t understand why it looks for a file .module.pom This file indeed does not exists.
Also it used to work correctly before yesterday (and I am not sure why - I guess there was a kind of workaround on GitHub package side).

Do you have any idea on why gradle is looking for a module.pom rather than the .pom file ?

2

Facing the exact same issue over here - and the same setup - Gradle + GitHub. Since the gradle wrapper is version-locked, I do not think this has something to do with gradle. Also, given the timeline of the OPs post, we also started facing the issue at the exact same time. We have raised a support ticket with GitHub, I’ll be linking this issue to them as well.

EDIT: Adding the following doesn’t help:

metadataSources {
    ignoreGradleMetadataRedirection()
}
3

We have been looking more in detail and actually the maven-metadata.xml file that is on GitHub does not match the one that is generated by gradle when publishing locally.

It seems that GitHub is generating automatically the meta file from the content of the directory and that while having locally
< snapshot>
< timestamp>20210411.011638</ timestamp>
< buildNumber>1</ buildNumber>
</ snapshot>
GitHub generates
< snapshot>
< timestamp>20210411.011638</ timestamp>
< buildNumber>1.module</ buildNumber>
</ snapshot>
So yes it looks like an issue on GitHub side, someone probably pushed an update that forgot to remove the file extension to compute the build number…

4

I’ve been trying to see if there is a way to post-process a maven-metadata.xml file via gradle scripts. So far I’ve tried using a ComponentMetadataRule but that doesn’t seem to help. If I can post-process a file, I’ll be able to do a string replace on <buildNumber>.*</buildNumber> to at least unblock the company on deployments - currently the entire pipeline has come to a halt over the last 1.5 days.

If anyone here knows how to post-process the maven-metadata.xml file when gradle processes it, that would be of great help.

5

Issue seems fixed on GitHub.