Gradle should allow pom.xml customization for Gradle Plugin Portal artifacts

[vlsi]

Expected Behavior

There should be a way to ensure pom.xml files are identical at Gradle Plugin Portal and at Sonatype OSSRH.

Current Behavior

Gradle deploys a different pom to the portal, so the users of Gradle Dependency Verification identify an unexpected difference: burrunan/gradle-s3-build-cache#8

Context

I deploy the plugin to both OSSRH and Portal (mainly for testing and signing reasons), and OSSRH mandates certain elements in the pom (license, etc).

[melix]

TBH I think the plugin portal shouldn't do anything special and use the regular publishing mechanisms. We have no concrete plans now but we're seriously thinking about it.

[jjohannes]

@vlsi the normal mechanisms of maven-publish should work here. If you use these two plugins in combinations, and do not change artefact/group via the plugin-publish specific mechanism, the same pom should be deployed everywhere.

plugins {                       
    id("maven-publish")                               
    id("com.gradle.plugin-publish") version "0.14.0"  
}

https://docs.gradle.org/current/userguide/publishing_gradle_plugins.html#plugin-publishing-plugin

You can customise the pom by configuring the publication created by the plugin-publish plugin:

publishing {
    publications {
        create<MavenPublication>("pluginMaven") {
            pom {
              // ...
            }
        }
    }
 }

I know this is not very intuitive and should be improved (i.e. maven-publish should be "enforced") in the future.

Can you check if this issue can be closed?

[PFCJeong]

@jjohannes Could you be more specific about "do not change artefact/group via the plugin-publish specific mechanism"?
Facing the same issue now

[jjohannes]

@PFCJeong I mean that you use Gradle's core mechanism for setting "group" and "artifact" that is also used in other places.

For artifact: The subproject's name is the artifact. For this you need to make sure the subproject has the name you expect in the include("my-artifact") statment in settings.gradle. Or, if you publish the root project, use rootProject.name = "my-artifact" in settings.gradle..

For the group use the global project property group in the build.gradle file:

group = "my-group"

[LunNova]

The generated pom is also missing the scmUrl even if it is set up in the pluginBundle extension, which stops some third party tools from associating repos (for the purposes of fetching changelogs) with the plugin.

Pom from publications: https://maven.minco.dev/dev/minco/gradle/defaults-plugin/dev.minco.gradle.defaults-plugin.gradle.plugin/0.2.43/dev.minco.gradle.defaults-plugin.gradle.plugin-0.2.43.pom
Pom from plugin portal: https://plugins.gradle.org/m2/dev/minco/gradle/defaults-plugin/dev.minco.gradle.defaults-plugin.gradle.plugin/0.2.43/dev.minco.gradle.defaults-plugin.gradle.plugin-0.2.43.pom

[jjohannes]

To clarify what, IMO, the longstanding issue is here:

• The portal generates the "marker poms" itself, although Gradle by now can create them directly. If you publish a plugin with maven-publish to any other repository, ironically, everything works well. But you have a different marker POM than in the plugin portal. Publishing to both Maven Central and the portal then leads to inconsistencies (as explained in the issue description and shown on the example above)
• Because of this, if you publish to the plugin portal you:
  • cannot change the POM to add author or license info
  • cannot sign the POM

As example, this POM
https://plugins.gradle.org/m2/org/gradlex/java-module-dependencies/org.gradlex.java-module-dependencies.gradle.plugin/1.6.1/org.gradlex.java-module-dependencies.gradle.plugin-1.6.1.pom

...should have the same licenses info and a *.pom.asc file as this POM:
https://plugins.gradle.org/m2/org/gradlex/java-module-dependencies/1.6.1/java-module-dependencies-1.6.1.pom

But there is no way to achieve that.

[melix]

unpopular opinion: the portal should only be an index of things published on Maven Central. Problem solved :)

[vlsi]

I am not sure Maven Central license would allow Gradle (or someone else) to index and publish contents.

However, it would indeed be great if there was no need to publish the artifacts twice.

The catch-22 is that publishing to Central is a little bit harder than publishing to Gradle Plugin Portal, so users get "not that good experience" which Gradle sadly can't control much.

I really hope Sigstore would get some spin soon so it would be easier to publish to Central.

[martinbonnin]

the portal should only be an index of things published on Maven Central.

+1

I am not sure Maven Central license would allow Gradle (or someone else) to index and publish contents.

I'd be okay if it's a manual index (see #225). Plugin authors could manage their metadata and update it on new release, etc... without the Gradle Plugin Portal having to crawl Maven Central.

[huehnerlady]

I in general do not care if the portal does something smart or not. what I do not like is that the portal is not keeping all the information.

So either just use what is already there OR at least put all the information the plugin has in its pom into the generated pom....

I have a similar problem, my scm information is lost which means that dependabot cannot find the release to that plugin.
Here is all the information about the plugin and when I publish it to local repository I can see all the information, but in the pom file in the plugin portal the information is missing