Distributed as a Gradle plugin

[tisonkun]

Ref https://github.com/spring-projects/spring-boot/tree/1.5.x/spring-boot-tools/spring-boot-gradle-plugin

[spencercjh]

Ref https://github.com/spring-projects/spring-boot/tree/1.5.x/spring-boot-tools/spring-boot-gradle-plugin

The library version of Gradle spring-boot used in 1.5.x is 2.9. The latest version is 6.1.1. It's here: https://github.com/spring-projects/spring-boot/blob/1.5.x/spring-boot-dependencies/pom.xml#L80. And I try to build a plugin locally with the latest gradle-core and associated libs but failed because of the breaking change of libs. Here is my playground: main...spencercjh:hawkeye:feat/gradle-plugin.

I think it's an out-of-date way to create a custom Gradle plugin by Maven because you can't find any docs about it except Spring 1.5.x. In spring boot 2, they refactor the whole project with gradle. We need more help.

Here are the official Gradle plugin implementation docs: https://docs.gradle.org/current/userguide/implementing_gradle_plugins.html.

[tisonkun]

Interesting. I don't take a closer looks. And I remember that current Spring Boot already use Gradle for management. I'm not sure if it's well supported to develop Gradle plugin with Maven.

Maybe @clayburn can give some advice here.

[clayburn]

@tisonkun I would not recommend trying to build a Gradle plugin using Maven, just as I would not recommend building a Maven plugin or extension using Gradle. While maybe possible with significant effort, you will find that it is not documented, and you would have to solve problems such as packaging and publishing on your own. The approach with least friction will be just to use Gradle and its support for creating it's own plugins.

While maybe a little clunky, a possible middle ground would to be to build the plugin using Gradle, but invoking Gradle via the exec-maven-plugin as part of a larger Maven build.

[tisonkun]

Then a potential workaround is building a Gradle project to wrap the core functions that published on Maven central. The downside is that it's clumsky to test the unreleased code when changes cover both the core functions and the Gradle plugin.

[spencercjh]

Each time you test the gradle plugin, you must first mvn install the hawkeye(-core or the whole proj), and then download the necessary dependencies from mavenLocal() in the gradle module.

Am I right?

Please give your comments 🙏.

[tisonkun]

Actually I tend to maintain the Gradle plugin in a new repository if it's not supported to develop with Maven.

[tisonkun]

as I would not recommend building a Maven plugin or extension using Gradle

@clayburn Actually, Gradle works well to manage Maven plugin projects, as spotless shows.

The point here is how to correctly package JARs and what metadata should be delivered. Spotless can release Maven plugin with Gradle because it uses mavenPlugin third-party plugin to generate the metadata a Maven plugin requires.

If Gradle defines public interface to populate/lookup plugin's metadata, I'm glad to invest some time to see if I can make a "Maven plugin for developing Gradle plugin", which basically conveys necessary dependencies as scaffolding and contains packaging logics to develier required metadata like .module files.

[tisonkun]

Something that can be referred spring-projects/spring-boot@9b15e6b

[tisonkun]

Here is another example for reference - https://github.com/joelittlejohn/jsonschema2pojo/blob/master/jsonschema2pojo-gradle-plugin/pom.xml

[tisonkun]

FWIW - gradle-module-metadata-maven-plugin.