While migrating my OSS from Maven Central to Bintray I realized I had a lot of duplicated Gradle scripts in different repos. I found some alternatives on how to share build scripts across repositories. I built on that and here is what I did.


The Gradle scripts are gathered in a script repository, see Gradle Scripts. The script repository is a Gradle project in its own that packages the scripts into a jar. That jar is added as a build script dependency in projects that needs the scripts.

This is really convenient when managing a large amount of repositories. Scripts, each adding a specific ability to the build process, can be gathered at one single place. Be released and managed in branches just like any other project. The dependency will also be cached, just like any other dependency, making the build much faster then applying a script form a URL.

This shows another advantage of Gradle compared to Maven. If I was using Maven I would have to create a pom that I would use as parent for these projects. Anyone using the project would also need that parent. So adding functionality to the build process would have negative effect on the built artifact. A parent would also risk adding too much functionality to the build process. If I had a Maven plugin and a pure library, I would not be able to construct a logical parent for them. With Gradle I just pick the abilities I want and there will be no trace, except the intended, in the built artifact.


In my case I use JitPack to build and supply the script jar. It means I can have a master branch where I can push changes to the scripts and immediately have those changes take effect in all my repos. But within an organization you would probably want to build and upload to something like Nexus or Artifactory.

A project using this method will have a very slim build script. A running example is the build script of my Violations Lib.