Inject license metadata into generated pom

[nmck257]

What problem are you trying to solve?

The pom.xml generated alongside this plugin (and its plugin marker artifact) do not include the license field.

Describe the solution you'd like

Here's something that worked in this other repo: https://github.com/openrewrite/rewrite-build-gradle-plugin/pull/4 ...though it still doesn't seem to include the license in the plugin marker artifact poms, and I haven't been able to figure that out.

Have you considered any alternatives or workarounds?

Additional context

Are you interested in contributing this feature to OpenRewrite?

I could make a trivial PR like above, but, I wouldn't mind if a savvier gradle user tried to get the same thing working for the plugin marker artifacts, too

[shanman190]

So this should effect the plugin marker already based on just looking at the upstream code of the Nebula Apache License plugin. https://github.com/nebula-plugins/nebula-publishing-plugin/blob/main/src/main/groovy/nebula/plugin/publishing/maven/license/MavenApacheLicensePlugin.groovy

A plugin marker is just a specially crafted Maven publication that is automatically generated as a side effect of registering the plugin ID. Since the upstream Nebula plugin uses publications.withType(MavenPublication) it'll capture this all just fine.

To verify this locally, I'd just apply the plugin, then run the publishToMavenLocal task and inspect the plugin marker pom file.

EDIT: reading back through Nick's original post and I finally noticed that it wasn't adding it already for the other repository. The reason for this is actually because the java-gradle-plugin creates the publications lazily in an afterEvaluate block. You can find another example of how to fix this here.

[nmck257]

@shanman190 thanks for the references!

So, I can adapt our repos here to do the publication modification in an afterEvaluate block. But, is it fair to say that the Nebula code could/should also be adjusted to register its Action as an afterEvaluate (?) or somehow later in the lifecycle (?), so that it just-works for plugin marker artifacts too?

[nmck257]

what's puzzling me is that when I run publishToMavenLocal, the marker artifact poms do get the license.

it looks like the publishPlugins task (used in the GH Action) does not include all the same marker-artifact-specific tasks which are included when I run publishToMavenLocal -- but, clearly some plugin marker artifact is getting generated? I'd like to check if publishPlugins generates some default marker artifact poms if needed, but, I'm having trouble mapping that task name back to the source code which registered it.

(this screenshot is from testing over on the rewrite-build-gradle-plugin, not on this repo)

[shanman190]

So on the right, all of those are tasks generated by the maven-publish plugin. The publishPlugins task comes from Gradle Plugin Publish plugin which I don't think is provided in an open source repository that I know of.

You are right though if the Nebula plugin was to move it's logic to an afterEvaluate everything would still work and it would cover this edge case.

[nmck257]

So I'm debugging the Gradle Plugin Publish plugin, and I think this code actually just ignores any customized plugin marker artifact poms.

The pink scribbles show how it collects up the artifacts to send to the plugin portal (checking a single publication by name pluginMaven), and the green scribbles show the other artifacts (ie the plugin markers) in memory which seem to be unreferenced.

And so I infer from there that Gradle Plugin Portal is generating the plugin marker artifact poms on the server side? If so, I should go raise a Gradle issue?

Does that logic check out?

[nmck257]

meanwhile, I've opened a PR to at least get license metadata into the plugin itself's pom #308

[shanman190]

I think it may be generating additional artifacts from the plugin descriptors (there look to be a few methods related there). I don't think that there is any server side generation, but I don't know for certain...

Next I'd probably track where the plugin descriptors are going from a data path standpoint.

The Gradle folks may have some ideas as well though, so I don't see any harm in opening an issue for help.

[timtebeek]

Following https://github.com/openrewrite/rewrite-gradle-plugin/pull/308 we now have a license in the generated pom.xml

• https://github.com/openrewrite/rewrite-gradle-plugin/pull/308

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- This module was also published with a richer model, Gradle metadata,  -->
  <!-- which should be used instead. Do not delete the following line which  -->
  <!-- is to indicate to Gradle or any Gradle module metadata file consumer  -->
  <!-- that they should prefer consuming it instead. -->
  <!-- do_not_remove: published-with-gradle-metadata -->
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.openrewrite</groupId>
  <artifactId>plugin</artifactId>
  <version>6.16.0-SNAPSHOT</version>
  <name>plugin</name>
  <description>Eliminate Tech-Debt. At build time.</description>
  <licenses>
    <license>
      <name>The Apache Software License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
    </license>
  </licenses>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.openrewrite</groupId>
        <artifactId>rewrite-bom</artifactId>
        <version>8.28.0-SNAPSHOT</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.jetbrains.kotlin</groupId>
      <artifactId>kotlin-stdlib-jdk8</artifactId>
      <version>1.9.0</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
</project>

https://oss.sonatype.org/content/repositories/snapshots/org/openrewrite/plugin/6.16.0-SNAPSHOT/plugin-6.16.0-20240524.212301-4.pom

By comparison: yesterday's snapshot did not contain a license: https://oss.sonatype.org/content/repositories/snapshots/org/openrewrite/plugin/6.16.0-SNAPSHOT/plugin-6.16.0-20240523.171710-2.pom

Is there anything left to do before we close this issue? Should we create a new release using this addition?

[nmck257]

@timtebeek no preference about releases from me, but I do plan to keep poking at the licenses for the plugin marker artifacts. If you'd rather have that carved away from this issue, that's fair