Is this plugin following best pracice?

I recently adopted the following plugin in order to generate android-like java references, so that badly referenced resources in files become build errors.

However I noticed that

  1. When changing the configuration options, that it didn’t regenerate the sources immediately, (Changing package name did not clear generated sources. · Issue #4 · PeppsHabender/r4j · GitHub)
  2. That it is prepending ‘Main’ to the classname that it is generating, which appears to be the sourceset that I was using. Realize this is probably required to disambiguate between different modules or test resources, but it was annoying me as I didn’t have control over the class name. ( changing class name only changes suffix. · Issue #3 · PeppsHabender/r4j · GitHub)
  3. That it wasn’t compatible out of the gate with task :sourcesJar and that I had to add dependencies to fix warnings (thanks gradle team for the new warnings that made me aware this was even an issue!) (r4j not compatible with task :sourcesJar · Issue #2 · PeppsHabender/r4j · GitHub)

Would anyone be able to have a look over (it’s a relatively small plugin) so that I might be able to attempt to fork it, and PR some changes to get it following gradle conventions more closely.

This is where it’s getting the ‘module’ name:

This is where it’s setting task dependencies explicitly:

This is where it’s setting the generated files as as sourceset

This is where the resource files are getting set, which seems to be difficult to configure filtering in gradle:

I’m not going to do a full code-review and I doubt you find someone else doing it.
But if you have questions about specific aspects, feel free to ask about them.

For example

That it wasn’t compatible out of the gate with task :sourcesJar and that I had to add dependencies to fix warnings (thanks gradle team for the new warnings that made me aware this was even an issue!)

The warning you get now sometimes is helpful, the solution suggestions are almost always non-sense.
Almost any explicit dependsOn where the left-hand side is not a lifecycle task is a code smell and a strong sign that you do something not correctly.
In that case, you probably do not have the code generation task (yes, the task itself or its task provider) configured as srcDir for the source directory set, but only configured the path and some manual task dependencies which is almost always bad.

If you have the code generation task registered as source directory, then any task needing source files including sourcesJar, compilation tasks, static analyzers, and so on, all get the full set of sources and automatically get the necessary task dependencies implicitly.

That would mean that your task dosnt declare ‘the configuration options’ as Input, a pattern which would be documented here: Implementing Custom Tasks
In the first line of the execution of your task I find:

    @TaskAction
    fun execute() {
        val config: R4JConfig = this.project.r4jConfig

Using the Project object at execution time is not compatible with the configuration cache:
https://docs.gradle.org/current/userguide/configuration_cache.html
And that would be my mini review, declare your inputs and make your task configuration cache compatible

2 Likes