opinionated or not

Opinionated framework on top of an unopinionated toolkit. If I had to choose my favorite engineering principle behind Gradle, there you go.

Sticking to the principle is challenging. Imagine a subdomain where the are no clear conventions, no popular, easy-to-harvest patterns. How do you come of with the “opinion” in such a field? We gather use cases and then try to resolve them in the best way we can. Sometimes the convention emerges organically and we can unanimously rejoice. Sometimes several conventions emerge and we are not quite sure which one to pick. We might choose the one most fitting or wait until we gather more knowledge, more use cases. Sometimes, we don’t see any reasonable conventions and we refrain from the opinion for the time being.

Good old ant doesn’t have many opinions. It is a toolkit. It lets me script the project automation in an imperative fashion. Kick starting a new software project almost always started with taking the build.xml from the previous project. The level of copy-paste in the build.xmls is legendary. Yet, back in the days, I loved ant as it allowed me to do amazing automation in projects. Thank you ant!

Maven delivers plenty opinions. It is a framework. However if my context does not quite fit maven’s opinion then I might be in trouble. It was a great technological leap from ant to maven. I can still remember my feverish efforts advocating maven2, pulling my conservative team mates into the new era of declarative dependencies and convention-over-configuration. Thanks, maven!

We want Gradle to offer the inspiring technological leap you might remember when you migrated your first project from ant to maven. This time, though, you will taste it when upgrading from maven. Some of you have enjoyed that feeling already and I am so glad to have you on board. Some of you will come along at some point I’m sure. We want to deliver opinionated conventions so that you can build your standard projects with a one-liner build scripts. We also want to provide an unopinionated toolkit so that you are never lock down with the design choices we have made.

I’ve just got back to Krakow from the amazing city of Berlin. I had a pleasure to brainstorm, debate and drink cytrynowka with the fellow Gradle gang members. Among many things that are crystal clear to me now is this one: The question is not IF Gradle will dominate the space of project automation but WHEN. Have a great weekend everybody :)