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

vlsi commented 3 years ago

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: https://github.com/burrunan/gradle-s3-build-cache/issues/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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

jjohannes commented 3 years ago

@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 commented 2 years ago

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 commented 8 months ago

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 commented 8 months ago

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

vlsi commented 8 months ago

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 commented 2 months ago

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 https://github.com/gradle/plugin-portal-requests/issues/225). Plugin authors could manage their metadata and update it on new release, etc... without the Gradle Plugin Portal having to crawl Maven Central.

gradle / plugin-portal-requests