So I think gradle has a lot of problems, but having access to Groovy anywhere is a good thing. You can always make your builds do what you want.

And as in all things if your code gets too complicated you need to refactor, extract logic into methods/classes, etc.

You can always make your builds do what you want, but the flipside is you can never understand what someone else is doing with their build. I don't think the build system is the place for turing-complete code. Business logic certainly doesn't belong there. Keep the build simple and standardized, and keep code in code.

I've arrived at the opposite opinion over time ... I think people need to recognise that a build system is code. When we pretend it isn't we ultimately end up contorting the system to make up for the missing flexibility. A lot of it looks declarative, but it is not always the case. Sometimes you want imperative constructs. The build should be recognized as code, maintained as code and use a first class language suited to the job.

I do have a problem with Gradle which is that it is almost entirely magical unless you are a pretty advanced Groovy programmer to understand how it is doing what it is doing. I have never felt more disoriented than when trying to learn how to customise a simple aspect of my build and having people post snippets that work but seem completely disconnected from anything else in the build process.

I think that when you do need code in your build that code should be first-class. Which means it should have test coverage, a release process, follow your coding standards and all the rest of it. The maven plugin model encourages that.

And maybe this is making a virtue of necessity, but I find the overhead of creating a plugin stops people from putting random "different compiler arguments on a Wednesday" conditionals in every build, which is all too common if you give them immediate access to a turing-complete language.

It's not "business logic", it's "build logic".

Your criticism applies equally to non-build code. Don't approve PRs for bad/inscrutable code.

In gradle you can build plugins just like maven. But a simple 'if then' doesn't require all the heavy lifting of a plugin.

> Your criticism applies equally to non-build code. Don't approve PRs for bad/inscrutable code.

But code is where logic goes. People expect logic there. It's the same objection as to logic/conditionals/looping in web templates, or routing config files, or persistence object mappers. If it's logic, it belongs in code!

There's a "spec" for Groovy at its website groovy-lang.org but that site's owned by a private individual so it could be pushing it to call it a real spec.

He means there's no spec for gradle files which are written using groovy.