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 :)

Building consistently

Last evening my friend told me a cool project automation story. Some guys came over to him:

-“Igor, our maven build fails. It works on my machine but doesn’t work on his.”
-“You don’t need me. Just make sure you have the same environment.”
-“I’m telling you, the environment is the same. We purged the local repo on both machines. The svn revision is the same. This is witchcraft and you need to exorcise our build”
-“Ok, tell what mvn -v says”
-“3.0.2”
-“Downgrade to maven 2 and stay happy”

Apparently, all team members use maven 2 and the build is not yet ready to upgrade the build client. Lessons learned:

• It’s easy to build your legend in a big company. Find a problem some guys are struggling with for past few hours. Then fix it in 5 seconds.
• It’s easy to fix this ultimate timeless IT problem “it works on my machine but not on his”. There’s a difference in environment and you simply have to keep looking until you find it. Just like the find-5-differences game.
• It’s worth all the money to have an environment that is consistent by design. If developers in a single team work on consistent environments it is heaps easier to tackle many problems. Here’s how you can implement this pattern with this nice build tool called Gradle:

The wrapper feature is something I underestimated at the time when I started using Gradle a couple of years ago. I thought that the main purpose of the wrapper was to enable running build on environments that did not have Gradle installed. The feature was not very interesting to me because on my environments Gradle was already installed. It was sometime later I discovered the most important edge the wrapper gives. It helps a lot to be few steps ahead towards consistent environments. Suffice to say, if you use the Gradle wrapper you will never, ever face the problem I described at the beginning. Every developer will be using the same version of the build tool giving better, more reliable build environment in your team. I’m never tired of promoting patterns that increase reproducibility of the builds. That’s what I require from the build: consistent results for given VCS version regardless of the environment.

More over, the gradle wrapper makes it easy to upgrade the build environments for every developer. You update the version in your gradle/wrapper/gradle-wrapper.properties file and next time a developer updates his working copy, he will use the newly blessed version of the build tool.

Gradle wrapper is just one of the ways. You can achieve similar results using other build tools if you are creative enough :) I remember years ago I was helping a team that had notorious problems with the build stability. After one of the retrospectives the team decided that *entire* environment would be versioned. They’ve created a VCS root for stuff like jdk, maven, plugins. They’ve even kept separate local maven repo for their project. All those efforts to minimize the random build failures and lengthy debugging sessions caused by inconsistent dev environments. That may sound extreme, nevertheless that’s how the team attempted to solve the problem.

Design your build environment so that it is easy to keep it consistent across the team members. You’ll notice you’ll smile more :)

Build consistently every day. Peace.