Customising the pom created by the Plugin Publish plugin

(awilkinson) #1

I’d like to be able to customise the pom that’s used by the publishPlugins task of the Plugin Publish plugin. My project already has the Maven plugin applied and its pom is customised as follows:

install {
    repositories.mavenInstaller {
        pom.whenConfigured { generatedPom ->
            generatedPom.project {
                // Configure name, description, url, licence, etc.
            }
        }
    }
}

It looks like the publishPlugins task is generating a separate pom file, build/publish-generated-resources/pom.xml. How can I customise this pom or, even better, have the publishPlugins task use the existing pom?

(Martin Nonnenmacher) #2

Three years later I am still facing the same problem. I followed the documentation to configure the Plugin Publishing Plugin:
https://guides.gradle.org/publishing-plugins-to-gradle-plugin-portal/

But I cannot find any information on how to customize the generated POM file. Not even the “vcsUrl” parameter is used to populate the SCM section of the POM file, and I also would like to add the typical information like license, organization, issueManagement, and so on. Is there really no way to do this?

(awilkinson) #3

FWIW, I never figured out how to do it. That was one of a few reasons why we stopped using the plugin publishing plugin.

(Martin Nonnenmacher) #4

Thanks for the info Andy, do you use the old maven plugin or the maven-publish plugin to publish to the plugin registry instead?

It’s kind of sad that there are three official plugins for publishing Maven artifacts and none of them fits all needs. And that the “new” maven-publish plugin is in incubation for over six years now (since Gradle 1.3) does not make me very confident that this will improve.

#5

Customizing the generated POM is possible for the “new” Maven publish plugin. We are doing this for years. Excerpt from how we do it:

publishing
{
	publications
	{
		mavenJava(MavenPublication)
		{
			pom.withXml
			{
				def pom = asNode()
				pom.appendNode 'description', project.description
				pom.appendNode 'inceptionYear', project.ext.inceptionYear

				def n = pom.appendNode 'organization'
				n.appendNode 'name', project.ext.organization
				n.appendNode 'url', project.ext.organizationURL

				n = pom.appendNode 'issueManagement'
				n.appendNode 'system', project.ext.issuesSystem
				n.appendNode 'url', project.ext.issues

				n = pom.appendNode 'ciManagement'
				n.appendNode 'system', project.ext.ciSystem
				n.appendNode 'url', project.ext.ci

				n = pom.appendNode 'scm'
				// ... and so on
			}
		}
	}
}
(Martin Nonnenmacher) #6

Thanks @twwwt, I am aware of that but it does not help with the Plugin Publishing Plugin.

Btw, you could use this syntax which I find more readable (credits go to @daz, see New publishing model and POM customization via XmlProvider) :

def pomConfig = {
    description project.description
    inceptionYear project.ext.inceptionYear
    
    organization {
        name project.ext.organization
        url project.ext.organizationURL
    }
 
    ...
}

publishing {
    publications {
        mavenJava(MavenPublication) {
            pom.withXml {
                asNode().children().last() + pomConfig
            }
        }
    }
}
#7

Ahh, sorry, I was kind of blind…

(awilkinson) #8

Neither. Instead we publish via Artifactory to Bintray. We then set the necessary metadata that allows the Plugin Portal to find the new plugin version. However, that’s far more influenced by our build and release process across several OSS projects than any deficiencies of Gradle. I’m not sure I’d recommend it in general.