Stop the f… about #Spring & #Hibernate migrating to #Gradle. Repeat after me: "my project do NOT have the same requirements" #Maven
— Nicolas Frankel 🇺🇦 (@nicolas_frankel) July 16, 2013
This was my week’s hate, and I take full responsibility for every character in it.
While that may seem like a troll, Twitter is not really the place to have a good-natured debate with factual arguments, so here is the follow up.
Before going into full-blown rhetoric mode, let me first say that despite popular belief, I’m open to shiny new things. For example, despite being a Vaadin believer - which is a stateful server-side technology, I’m also interested in AngularJS - which is its exact opposite. I’m also in favor of TestNG over JUnit, and so on. I even went as far as going to a Gradle session at Devoxx France! So please, hear my arguments out, only then think them over.
So far, I’ve heard only two arguments in favor of Gradle:
- It’s flexible (implying Maven is not)
- Spring and Hibernate use it
Both are facts, let’s go in detail over each of them to check why those are not arguments.
Gradle is flexible
There’s no denying that Gradle is flexible: I mean, it’s Groovy with a build DSL. Let us go further: how is flexibility achieved? My take is that it comes from the following.
- Providing very fine-grained - almost atomic operations: compilation, copying, moving, packaging, etc.
- Allowing to define lists of those operation - tasks: packaging a JAR would mean copying classes and resources files into a dedicated folder and zipping it
- Enabling dependencies between those: packaging is dependent on compilation
If you look at it closely, what I said can be applied to Gradle, of course, but also to Ant! Yes, both operate at the same level of granularity.
Now the problem lies in that Gradle proponents tell Gradle is flexible as if flexibility was a desirable quality. Let me say: flexibility is not a quality for a build tool. I would even say it is a big disadvantage. That’s the same as having your broken arm put in a cast. That’s a definite lack of flexibility (to says the least) but it’s for your own good. The cast prevents you from moving in a painful way, just as unflexible build tools (such as Maven) make strange things definitely expensive.
If you need to do something odd over and over because of your specific context, it’s because of a recurring requirement. In Maven, you’d create a plugin to address it and be done with that. If it’s a one-shot requirement, that’s probably no requirement but a quirk. Rethink the way you do it, it’s a smell something is definitely fishy.
Spring and Hibernate both use Gradle
That one really makes me laugh: because some framework choose a build, we should just use theirs, no questions asked? Did you really check why they migrated in the first place?
I won’t even look at the Hibernate case, because it annoys me to no end to read arguments such as "I personally hate…" or "…define the build and directories the way that seemed to make sense to me". That’s no good reason to change a build tool (but a real display of inflated ego in the latter case).
For Spring, well… Groovy is just in their strategic path and has been for years. SpringSource Tools Suite fully support Groovy, so I guess using Gradle is a way to spread Groovy love all over the world. A more technical reason I’ve heard is that Spring must be compatible with different Java versions, and Maven cannot address that. I’m too lazy to check for myself but even if that’s true, it has only a slight chance of applying to your current project.
Gradlew is one cool feature
The only feature I know of that I currently lack - and would definitely love to have, is to set the build engine version once and for all, to be able to run my build 10 years from now if I need it. It’s amazing the number of software products that go to their first maintenance cycle in years and are at loss building from sources. Believe me, it happened to me (in a VB environment) but I had the fortune to have a genius at hand, something I unfortunately cannot count on.
In the Gradle parlance, such feature is achieved through something known the Gradle Wrapper. Using that downloads the build engine itself, so you can put it into your version control. Too bad nobody ever raised this as an argument 🙂 though this is not enough to make me want to migrate.
Note: during this writing, I just searched for a port of this feature to Maven and I found maven-wrapper. Any feedback?
Wrap-up
TL;DR:
- Gradle is just Ant with Groovy instead of XML
- Your context is (probably) different from those of frameworks which are using Gradle
Both points have only one logical conclusion: there’s no real reason to use Gradle, stop the f… about it and go back to develop the next Google Search, there’s much more value in that!