Exit Full View

Meta Build / README.md

Meta-Build

Creates gradle build scripts from a much smaller build script.

Gradle really annoys me. I use gradle in a realatively simple manner. I just want it to handle maven dependencies, and build these targets : jar, application (installDist), dokka, publish...

Things that are wrong with Gradle

  • I don't want to split my build script into many different source files.
  • I don't want extraneous cruft.
  • I don't want to repeat myself.
  • I don't want to restate the reposities for each subproject.
  • I don't want the API to constantly change.
  • I don't want to rewrite my build script just because I'm using a later version of Kotlin (or some other component).
  • I don't want plugins.
  • I don't want any special values, (Using gradle, the kotlin version number cannot live in the same place as all other version numbers).

My ideal build script

  • I want a simple script (just 1 file)
  • I want constants (such as version numbers) together, near the top of the build script.
  • Declare the requirements for each subproject in a concise manner.
  • The API should be simple, and the documentation easy to find in one place. Because gradle is split into its core and many plugins, the documentation is never easy to find.

Solution

I considered writing a build too from scratch, but that is too much effort, and wouldn't be a godd solution even if I did, because I'd also need to write plugins for various IDEs.

So instead, I have a very small amount of code, which translates a small, simple build script into standard gradle build scripts.

I never have to write, or look at a gradle script ever again. Yay!

Notes

This solution is pretty bad, and I doubt many other people will like it.

I've written the bare minimum for my needs, and there's a very good chance you need something that metabuild doesn't support.

In particular :

  • Only JVM projects are supported (but multiPlatform projects will be added soon).
  • Publishing maven artifacts only supports HttpHeaderCredentials and HttpHeaderAuthentication. (I don't plan on providing any other publishing methods).

I deliberately go against what gradle developers consider best practices.

For example, I encourage you to declare the list of repositories only once. Whereas Gradle encourages you to declare them one per subproject (or jump through convoluted hoops).