Plugins and mavenCoordinates

Help/Discuss
1

I tried publishing a plugin recently and was told that the legacy (and default) group naming is no longer supported and that I needed to add a mavenCoordinates block to manually specify the coords.

I now get:

> Task :testkit-junit5-plugin:publishPlugins FAILED
Could not reuse POM from pluginMaven publication because mavenCoordinates() was used

What is wrong here?

gradlePlugin {
    plugins {
        testkitJunit5 {
            id = '...'
            implementationClass = '...'
        }
    }
}

pluginBundle {
    ...

    plugins {
        testkitJunit5 {
            ...
        }
    }

    mavenCoordinates {
        groupId = project.group.toString()
        artifactId = project.name
        version = project.version.toString()
    }
2

What is even more strange is that this works for other plugins I publish.

3

Are you using both maven-publish and com.gradle.plugin-publish plugins?

4

Thanks for the reply @Schalk_Cronje

The plugin project is actually multi-project - there is a plugin as well as separate java-library module.

So yes, I do apply a few publishing related plugins:

  1. io.github.gradle-nexus.publish-plugin to be able to publish the java-library to OSSRH. This plugin unfortunately is required to be applied to the root project.
  2. com.gradle.plugin-publish for publishing non-snapshots of the plugin to the portal.
  3. maven-publish to publish “local snapshots” of the plugin.

I actually have almost the exact same setup that works with other plugin projects. The differences are:

  1. The multi-project nature
  2. Applying io.github.gradle-nexus.publish-plugin (because of the multi-project)
5

So is there a best practice to producing plugins whose classes are needed on the user’s classpath?

Here, the plugin registers some JUnit Platform extensions and produces some classes that the user would then use inside their JUnit tests (JUnit’s ParameterResolver stuff). I asked on another topic about how to share these classes so that the user can access them from JUnit tests and was told I’d basically have to publish those classes as a separate library the users testImplementation would depend on.

Having the 2 projects in one build is nice from the “keep versions in sync” perspective.

Is there an alternative that allows me to achieve both?

6

There are many ways to achieve that.
You could e. g. pack all classes (the plugin and the JUnit extension) in one artifact and then add the same to the build script class path and the test class path, but then you can also access the plugin and so on in the test classes.
You could have one build that produces and publishes two artifacts so that you can version and release them together easily and then add a dependency to that second artifact to the test class path.
Or you could maybe add your dependency as a SelfResolvingDependency where you return a Set<File> of the files that make up the dependency, you chould e. g. have the JAR with the JUnit extension packed as resource in your plugin jar, unpack it to some place and then add it as self-resolving dependency or something like that.

But I guess properly releasing as separate jar and adding to the class path is the cleanest way. It could then be used even without your plugin, IDEs can download the sources and JavaDocs, …