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!