Gradle closure hack

[Kenneth Knowles <kl...@google.com>]

Getting into the spirit of Groovy/Gradle style, can we make
"applyJavaNature" look like these other config blocks?

    applyJavaNature { // maybe this should be called beamJavaModule
      errorprone {
        ... errorprone config ....
      }
    }

If I understand correctly, this should also have some benefit of allowing
more fine-grained overrides than you can get with just the booleans. Or,
conversely, it will allow us to avoid having flags while also avoiding
build_rules knowing all the details of modules and whatnot.

Kenn

Re: Gradle closure hack

[Lukasz Cwik <lc...@google.com>]

This is a good idea because it is in tune with how people familiar with
Gradle think.

When I started applyJavaNature, I couldn't think of a good way to get
certain closures to apply to more then one task. For example, we have a
default shading configuration which we want to apply to both the main
classes and test classes and I couldn't figure out at the time how to get
applyJavaNature {
  shadowJar {
     ... shadowJar config ...
  }
}
to also apply to the shadowJar for test classes task that is created in
build_rules.gradle. Note that there is no shadowTestJar closure part of the
shadow plugin and the shadowJar block only applies to the default shadowJar
for main classes task that is automatically created by the plugin.

The other issue I was battling with is how much customization do we really
want within a project when it comes to build files. The more customization,
the harder it is for a contributor to know the nuances of each module and
how it is built/works differently then other modules. Imagine if all the
modules were built differently, what would our contribution guide look like?

The best I could think of with these two constraints in mind was to add a
configuration closure which is specific to applyJavaNature so it seemed
more natural like Gradle. For example:
applyJavaNature {
  shadowClosure {
     .. shading config ...
  }
  enableFindbugs
  enableSpotless
}

I just didn't have the time to be able to do what I describe above and felt
that the usage of the named arguments was a pretty good compromise.

On Wed, May 23, 2018 at 4:15 PM Kenneth Knowles <kl...@google.com> wrote:

> Getting into the spirit of Groovy/Gradle style, can we make
> "applyJavaNature" look like these other config blocks?
>
>     applyJavaNature { // maybe this should be called beamJavaModule
>       errorprone {
>         ... errorprone config ....
>       }
>     }
>
> If I understand correctly, this should also have some benefit of allowing
> more fine-grained overrides than you can get with just the booleans. Or,
> conversely, it will allow us to avoid having flags while also avoiding
> build_rules knowing all the details of modules and whatnot.
>
> Kenn
>