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.

IDE & patterns for huge maven project

I started working on a huge multi-module maven project these days. Trust me, working with ~150 maven modules at a time is a pain for a developer. On the other hand there’s a lot of room for me to improve the development environment & make dev cycles efficient.

Some more context: The team is pretty big; over 100 developers on a single codebase working in a ‘continuous integration’ fashion: little branching, keeping the integration gap small, automated testing, CI servers etc. Each developer checks-out entire trunk that contains ~150 maven modules linked via the default ‘x-SNAPSHOT’ dependency. Maven veterans probably flinch now because this way of managing internal dependencies in a large project is probably considered ‘lame’. Maven ‘by-the-book’ approach may put emphasis on keeping the internal dependency links to a specific version. I’m a pragmatic developer and I see pros & cons of both approaches. This blog post, however, does not dwell on the subject of internal dependencies. I want to focus on the most effective dev environment set-up and the choice of the IDE.

“Toggle IDE/local-repo dependency” pattern

Couldn’t find a good name for this pattern. Theoretically, it can give a nice dev performance boost in a huge multi-module project. Here’s the idea: out of the 150 modules we will work on the handful only. Therefore I want to be able to quickly decide which module should be a concrete project/module in the IDE and which should a mere jar dependency resolved via the local maven repo. It is a sort of a toggling dependency IDE/local-repo.

Here’s how I see it working:

1. The developer pulls in a smaller module set into an IDE by selecting a relevant sub-parent in the multi-module tree.
2. At some point the developer needs to perform changes in the module that is not pulled into the IDE. He pulls in the relevant module(s). Dependencies inside IDE are updated from jar-dependencies to: project-dependencies (Eclipse) or module-dependencies (IDEA).

Here’s how my team so far coped with the project and how the above pattern could be used.

eclipse:eclipse or idea:idea

At the moment I think more than half of the team uses maven eclipse:eclipse plugin to generate configuration that is consumable by Eclipse. In our environment it is not very efficient because after every svn update developer has to regenerate project configs (in case someone changed internal/external dependencies) and restart Eclipse (‘just’ refreshing Eclipse didn’t work well occasionally).

Team members who use IntelliJ IDEA never use idea:idea maven plugin. I cannot confirm that but I heard feedback that it was not generating the correct configurations for latest & greatest IDEA. However, most devs simply don’t need idea:idea because maven support built-in to IDEA 9+ is simply brilliant. I hardly imagine someone wanting to step back and generate configurations via idea:idea.

Toggling dependencies IDE/local-repo is possible but somewhat inconvenient. It requires specifying project names by hand at command line; then refreshing/restarting IDE.

M2Eclipse

I don’t recall anyone using it in my team. The plugin seems to be making progress – I heard several good reviews. In our particular environment developers complained on reduced perceived performance of Eclipse and they fell back to generating configs via eclipse:eclipse. I tested m2eclipse myself recently with our project; there were things I liked about it. Yet, I still found Eclipse choking (even If I fine-tuned the plugin).

Toggling dependencies IDE/local-repo is possible but I cannot comment how it behaves as we haven’t used m2eclipse too much.

IntelliJ IDEA

The built-in maven plugin for IDEA is getting more & more popular in my team. It does not seem to reduce the perceived performance of the IDE. However, IDEA tends to be a bit slower than Eclipse anyway. IDEA 9+ is fast enough for me – I tend to use it more often than Eclipse. My experience with IDEA 8- is limited because I rarely had enough patience to wait until it started. Spanking new IDEA 10 is marketed as faster than 9. I have not tested it yet but I want to extend my thanks to JetBrains for working on it!!!

Back to the maven support in IDEA and the context of our huge multi-module project. Options that we absolutely needed to tweak were:
1. Disable files/folders synchronization on IDEA frame activation. In our case, IDEA choked every time one ran any maven goal outside of the IDEA.
2. Disable automatic maven project reimporting (it’s the default anyway). It is related to the #1.

Also, be sure to read some of the posts on how to improve IDEA performance in general (most notable: choose wisely the plug-in set enabled at IDEA; get SSD drive; etc.)

In our project we found this feature very useful: the separation of 2 different actions: ‘reimporting maven projects’ and ‘updating folders’. The first one makes sure the project internal/external dependencies are linked well. The latter makes sure sources are generated for modules that need them (generate-sources).

Finally, toggling dependencies IDE/local-repo works like a charm in IntelliJ!!! Basically, all I need to do is “Import module from existing model”, point out the relevant pom.xml. IDEA takes care of updating the dependency links of my existing modules to use IDE links rather than local-repo links. How cool is that?!

I still keep myself using both Eclipse & IDEA as I work with various developers. However, it’s going to be harder to get back to Eclipse…

Disclaimer: Please notice the date of this blog post! I don’t know if the problems I mentioned with some of the tools will still be valid in future. Hopefully all those tools will be great, fast & very convenient for working with huge maven projects. Respect to all the people who work on the dev tools that we use today (Eclipse, IntelliJ IDEA, eclipse:eclipse, idea:idea, m2eclipse). Thanks a lot!!!

build systems @ devoxx

I couldn’t attend to the session on gradle because there was a Mockito session at the same time. For some unknown reasons I chose Mockito…

About gradle. Later on, Hans Dockter (AKA the gradle guy) was kind enough to help me writing a build.gradle for Mockito. Also, we played with multi-project builds and brand new gradle jetty plugin.

Then I went to Jason Van Zyl’s session, mostly on maven3. Third time lucky, right? Let’s not mention M1 or M2 here because I would have to use words gentlemen don’t use. Maven3 looks quite promising and I wonder what’s gonna be my first choice build system in mid-2009: gradle, maven3, or maybe something else? Felix made a wild experiment and cut an interesting, object-oriented java build system.

Oups, did I just call maven a build system? Oh, I know it is “not just a build tool” but 94.72% of developers use it to build projects so pardon me for taking this mental shortcut.

After Jason Van Zyl’s session I had an impression that he believes the best fit for the build system is a declarative architecture. I tend to disagree and I believe the build has inherent scripting nature. Then the natural fit for the build system is some scripting language. Quick reminder: xml is not a scripting language. Fully declarative build system like maven makes me eventually hit the boundary – it’s when the stuff that can be declared or configured is not good enough. Then I need a painless way of “specialising” my build, for example by scripting. Mind that I’m not nearly a build architect so don’t take my rambling too seriously.

I didn’t meant to complain about maven – there are many really good ideas in it. However, allow me to have my favorite build system different from maven. Good luck with your maven builds. You’ll never know when they stop building…