Boilerplate reduction/reuse patterns across similar projects

I’ve been using Gradle for a few years now. Trying to centralize and encapsulate repository and plugin configuration is an area where I’ve struggled with it at times. It would be great if script plugins could apply other plugins and if repository and plugin resolution configuration were easier to centralize, but currently those areas are limited or incubating.

It’s hard to talk about these issues without a working example, so I’ve published a project that goes into some of the practical considerations for dealing with private repositories and trying to reduce boilerplate across projects with Kotlin testing support as the use case.

I’m interested in feedback or other examples of ways to centralize this kind of configuration. My understanding is that a compiled plugin could use the PluginManager, but I think there would still be some gotchas with resolving the dependencies. Have others struggled with these issues and found better solutions?

3 Likes

I’ve made a few updates.

  • Updated to Gradle 4.7.
  • Removed the JUnit plugin since Gradle now includes it.
  • Minor version bumps.
  • Some clarifying improvements.