Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PublishException: Cannot publish module metadata where component artifacts are modified. #301

Closed
swankjesse opened this issue Sep 3, 2021 · 3 comments · Fixed by #302
Closed
Labels

Comments

@swankjesse
Copy link
Contributor

Hi! I’m attempting to adopt the new base plugin for Wire. It’s a Kotlin Multiplatform project with a Gradle plugin, so it exercises lots of stuff!

Unfortunately publishing fails in this task:

> Task :wire-grpc-client:publishJvmPublicationToMavenCentralRepository

The failure exception is:

PublishException: Cannot publish module metadata where component artifacts are modified.
        at org.gradle.api.publish.maven.internal.publication.DefaultMavenPublication.checkThatArtifactIsPublishedUnmodified(DefaultMavenPublication.java:811)
        at org.gradle.api.publish.maven.internal.publication.DefaultMavenPublication.getPublishedFile(DefaultMavenPublication.java:768)
        at org.gradle.api.publish.internal.metadata.ModuleMetadataSpecBuilder.artifactFor(ModuleMetadataSpecBuilder.java:173)
        at org.gradle.api.publish.internal.metadata.ModuleMetadataSpecBuilder.artifactsOf(ModuleMetadataSpecBuilder.java:160)
        at org.gradle.api.publish.internal.metadata.ModuleMetadataSpecBuilder.variants(ModuleMetadataSpecBuilder.java:128)
        at org.gradle.api.publish.internal.metadata.ModuleMetadataSpecBuilder.build(ModuleMetadataSpecBuilder.java:92)
        at org.gradle.api.publish.internal.metadata.GradleModuleMetadataWriter.moduleMetadataSpecFor(GradleModuleMetadataWriter.java:84)
        at org.gradle.api.publish.tasks.GenerateModuleMetadata.computeModuleMetadataSpec(GenerateModuleMetadata.java:227)

It’s the main jar binary that’s failing to publish:

DecoratingPublishArtifact_Decorated wire-grpc-client-metadata:jar:jar:

The available artifacts are sources and javadoc:

0 = {PublishArtifactBasedMavenArtifact_Decorated@23764} "PublishArtifactBasedMavenArtifact_Decorated jar:sources"
1 = {PublishArtifactBasedMavenArtifact_Decorated@23765} "PublishArtifactBasedMavenArtifact_Decorated jar:javadoc"

I can reproduce by checking out the PR’s branch and running this:

 ./gradlew -p wire-library  :wire-grpc-client:generateMetadataFileForKotlinMultiplatformPublication  --stacktrace --info

I’m trying to figure out what the heck is going on and what I should change to fix it. I’ll update this issue if I find anything.

@swankjesse
Copy link
Contributor Author

I think I found a fix. I added this to my multiplatform project’s build.

val metadataJar by tasks.getting(Jar::class)
configure<PublishingExtension> {
  publications.withType<MavenPublication>().named("kotlinMultiplatform").configure {
    artifact(metadataJar)
  }
}

@gabrielittner
Copy link
Collaborator

Thanks for all the details.

Another workaround seems to be wrapping the configure call for multiplatform into afterEvaluate:

configure<MavenPublishBaseExtension> {
  afterEvaluate {
    configure(
      KotlinMultiplatform(javadocJar = Dokka("dokkaGfm"))
    )
  }
}

I need to look at it a bit more closely but I think that this old workaround might be the issue: https://github.com/vanniktech/gradle-maven-publish-plugin/blob/master/plugin/src/main/kotlin/com/vanniktech/maven/publish/Platform.kt#L146-L152 It's adding an empty sources jar to the kotlinMultiplatform publication if there isn't one yet. We had this because before 1.4.30 the Kotlin MPP plugin didn't create one which then tripped up the checks that Sonatype runs. In the non base plugin this code is always called in afterEvaluate so it didn't cause any issues. When you call configure from the base plugin in your build file then it seems to happen before the Kotlin MPP plugin configures the publication.

If my assumption is correct we can simply remove the workaround for the next release Kotlin 1.4.30 has been out for quite some time so I think it's reasonable to require at least that version.

@swankjesse
Copy link
Contributor Author

Thanks for the update. Looking forward to the fix; waiting for 1.4.30 to be ubiquitous sounds like a good plan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants