Home > Java > Stop the f… about Gradle

Stop the f… about Gradle

Stop the f… about #Spring & #Hibernate migrating to #Gradle. Repeat after me: “my project do NOT have the same requirements” #Maven

This was my week’s hate tweet, 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:

  1. It’s flexible (implying Maven is not)
  2. 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!

email
Send to Kindle
Categories: Java Tags: , , ,
  1. July 21st, 2013 at 15:42 | #1

    I’m not a Gradle fan (maybe because I tested & used it during its early stages), but you cannot say “Gradle is just Ant with Groovy instead of XML”

    Gradle provides “standard tasks” and dependencies over these tasks, which makes “standard lifecycles”.
    NIH syndrom and reusability, which is a black point on Ant, is not there with Gradle.

    As with Maven, with a really simple build.gradle (such as http://bit.ly/19bq7KM), you benefit from a standard java build which will compile, execute tests, package etc..

    Moreover, as with Maven (and parent poms), you can create & share plugins amongst your builds to standardize your build on a corporate level.

    The strongest argument against Groovy on my side, is the lack of completion in the IDE (which makes something based on a dynamic language hard to begin with).
    With Maven, we have :
    - XML structure & XML schema which allow simple XML editors to offer completion on “basic” Maven XML tags (this is why I don’t think Polyglot Maven is a good idea)
    - Plugin metadata which allows advanced IDE to offer plugin configuration’s auto completion & documentation

  2. July 21st, 2013 at 16:05 | #2

    Gradlew is not a feature, it is a workaround the fact that Gradle is not as many installed as Maven or Ant. It doesn’t help much reproducibility of the build. Ant and Maven has been very carefully being kept backward compatible, I see no worries on that side. The issue in reproducible builds are the “plugins” which are resolved at build launch time. And things which could be resolved one day may change over time since it often relies on external resources (it really shouldn’t but shit happens). The things which should be checked in the version control are the plugins, not the tool itself.

  3. July 21st, 2013 at 16:25 | #3

    +1. I always don’t find a real argument to switch from maven to gradle unlike from ant to maven a long long time ago that may justify such migration costs. There are few things interesting in it and for sure being an advanced maven user my limit when I say “fuck” to maven is probably far from the one a classical user may have. It enlight always the same thing : how to help maven users to go further … (I have in mind to push few articles in my blog to see if we can back port them later on the official website – and improve its readability …)

  4. July 21st, 2013 at 16:45 | #4

    I think you’re missing the whole point about Gradle here. It’s not a “better Ant”, nor a “better Maven”. You can’t just say that because it uses Groovy, it’s flexible.

    Gradle allows you to:
    1. define builds in a declarative way, just like Maven (this is totally missing from Ant)
    2. define your *own* conventions (totally missing from Maven)
    3. allows you to write extensions as well as plugins in an imperative way (yes, that’s really useful)
    4. allows you to generate pom.xml, as well as defining what it the output of your build. You’re not doomed to the single artifact paradigm (please take a look at the Gradle android build if you don’t get it: Gradle allows you to generate all the artifacts for combinations of various criteria (debug, release, paid, free, x86, arm, …) in a *declarative* way.
    5. allows you to build custom lifecycles, which is a very important thing for continuous integration and enterprise builds
    6. handles modules (subprojects) and incremental builds properly. Allows you to define your own incremental tasks. Not Ant nor Maven nor any other build tool has such a feature.

    A blog comment is definitely not the place to describe all the benefits of Gradle, but I can’t let you say things like this because it’s totally *wrong*.

  5. July 21st, 2013 at 17:15 | #5

    Gradle is not just Ant using Groovy instead of XML. Gant is Ant using Groovy instead of XML Gradle exists because Gant could not be a proper build framework to replace Maven. Gradle replaces Maven.

  6. July 21st, 2013 at 23:49 | #6

    I am sorry to say that I still do not understand why I should use maven as my building tool instead of Gradle in my next Java software project ? Because it is not flexible ?

    I don’t think you can affirm that there is “no reason using Gradle” given that any project has different requirements and constraints. Android development moved to Gradle and IntelliJ. Do they have interest into promoting Groovy ? I don’t think so. I think that they found out that these tools were the most adapted ones to their context. Period. And it may happen to any project…

  7. July 22nd, 2013 at 12:45 | #7

    @Cédridc Champeau
    Great, at least some arguments instead of feelings. Here are my counter-arguments:

    1. OK
    2. I do not want my own conventions. That is exactly what I try to avoid: I want everyone to do the same, so I don’t have to spend days understanding specific conventions, because someone ego thought src/tests/java was a better name than Maven’s conventions (test without an ‘s’)
    3. I do not understand the difference you make between extensions and plugins.
    4. Maven let you use qualifiers to differentiate between related outputs. See Javadoc and Source plugin to see these in use
    5. Noooo! See point 2
    6. Incremental compilation is lacking in Maven, I agree. Is it what you’re refering to?

    (I edited your comment to put numbers, it’s easier to reference your points this way)

  8. July 22nd, 2013 at 22:46 | #8

    @Nicolas Frankel
    2. Gradle comes with default lifecycle implementation, like maven. The difference is you can add “phases” easily during this standard lifecycle.
    In Maven, if you attach more than 1 plugin to the same phase, you must cross fingers they are not interdependents (which is, I concede, generally the case) otherwise real execution will be relatively randomized (based on plugin declaration ? what if the order is different between /project/build/plugins and /project/build/pluginManagement ?)
    In Gradle, you could easily inject a “phase” between 2 standard “phases” if needed, to differenciate these executions

    4. I think you’re mixing Maven Profiles and Classifiers (I don’t know any “qualifier” thing in Maven). Are you _really_ satisfied about the way Maven handles _conditionals_ ?
    I find it ultra verbose : what if you want to share some build configuration / behaviour between 2 profiles ? That’s generally a pain.

    5. I admit the “own lifecycle” stuff is a sharpened edge.
    But the difference with Ant is, to my opinion, that this is intended not for “basic usages” but to provide potential great powers to plugins allowing to handle specific cases.
    This is the case for the Android build, and this is a strength to my opinion, in favor to Gradle : this is not intended to build “java only” projects.
    Java is handled, but plugins/extensions have sufficient powers to provide “unplanned” build behaviours (Android was not there when Maven was born in mid-2000).
    Don’t say I’m encouraging people to create their own lifecycle, but it will allow “advanced users” (such as plugins creators) to do so and share & improve their builds.

    With Gradle, you could imagine to build & share a standard “enterprise java” plugins which would provide :
    - Standard code quality metrics (cobertura/jacoco, checkstyle/pmd/findbugs)
    - Standard release lifecycle
    - Standard JEE server deployment
    - Generate source & javadocs
    etc..
    Today, to handle this, every company will have to write its own parent pom which will pick always the same plugins ever and ever and ever.
    Yeah, I know, they will be free to chose their plugins, take good versions (latest available ?) … but it will take time, without having a real “standard java project build” emerging.

  9. Yann Le Moigne
    July 22nd, 2013 at 23:34 | #9

    I really like maven. But since one year I’m a Gradle user.

    If the assertion “readabilty increase both comprehension and maintenability” is true for code, it’s also true for describing a build pipeline.

    IMHO, gradle build files are much more readable than pom

    But when maven 3 will go out[1], it will be polyglot[2] so my argument is pointless ;)

    (Also, using gpars to sign a lot of jar preparing a Java Web Start deployment decreased our build time by a factor of 5, but I’s another story)

    [1] Yes, I know it is
    [2] http://blog.sonatype.com/people/tag/polyglot-maven/

  10. July 23rd, 2013 at 15:48 | #10

    I find it comical that you say it is a “real display of inflated ego” for me to decide to use Gradle rather than Maven for whatever the reason(s) for a build I have to use multiple times every day, yet its OK for you to sit there as someone I have never seen contribute to Hibernate (and probably build it, what, once a year?) and say that Hibernate should use this or that build tool because you happen to use that build tool. And I have an “inflated ego” for my opinions in that wiki? lol.

    So rather than look at random quotes you happened to pull out of context, why don’t you look at the context of those quotes:

    1) “I personally hate…” – “I personally hate the notion of combining “inherited pom data” and “module aggregation” into a single file”. Its an opinion dude. I make that pretty clear. And its not just my opinion. As I stated in the wiki quite a few of the Maven developers at the time agreed with me. So your opinion is more valid than mine? lol. Well you can keep your opinion in regards to what you use for build tool in your projects. I am not trying to force you to use Gradle. I find it hilarious that you are trying to say that projects like Hibernate, Spring, Android, Groovy, etc should use what ever build tool you happen to use because you happen to use it. I think you might want to look into the “inflated ego” mirror here ;) I also love how you pulled a quote out of context from one bullet point out of 8. These 8 actually discuss the short comings of Maven that made me look for alternatives.
    2) “…define the build and directories the way that seemed to make sense to me” – this comes from the points about why I chose Gradle as the replacement. Again you chose to pull a single partial comment from one bullet out of 9. I see a theme here with you and pulling quotes out of context to make your points; you work in management don’t you :)

    I already laid out the arguments why I (1) no longer use Maven and (2) now use Gradle. You just spew FUD. I won’t re-iterate my points here (see the linked Hibernate wiki I wrote). I personally could care less what build tool you use. I am very happy using Gradle over Maven in Hibernate; I cannot even begin to tell you how much happier. *Disclaimer – Nicolas, since you seem to have some difficulty recognizing opinions of others… this is an opinion :) Its my opinion. It effects what I do daily. It effects your daily work in no way. For you to say my opinion on what I do is irrelevant and that I should do what you want is really the epitome of “inflated ego”.

    By the way, you have a very distorted view of Gradle. To say that “Gradle is just Ant with Groovy instead of XML” is laughable and really is the piece that shows you have never even seriously looked at Gradle, let alone used it. Gradle, just like Maven and other build tools out there are based on “build by convention”. In fact, for “simplisitc” projects, the Gradle build file is actually *much smaller* than the corollary Maven build file. On the one hand you seem assume that all builds in the world are as simplistic as yours apparently are and therefore don’t need the flexibility Gradle allows. On the other hand, you go on to say that even if there are more complex and use that flexibility it is actually the fault of the build as being “definitely fishy”.

    Does Spring just use Gradle because it has some alliance with Groovy? I did not realize that. I did not realize you were privy to the thought process of the Spring development team and why they do what they do. But, what ties do do Hibernate, Android, etc have to Groovy/Gradle? What about the very well respected Thoughtworks Tech Radar? They place Gradle in its Adopt category (“We feel strongly that the industry should be adopting these items”) and Maven in its Hold category (“Proceed with caution”)? The latest is here. http://thoughtworks.fileburst.com/assets/technology-radar-may-2013.pdf I assume your “Gradle conspiracy” extends to them also? I think its time to ask what ties *you* have to Maven ;)

  11. July 23rd, 2013 at 16:38 | #11

    @Frédéric Camblor

    Your item number 5 is spot on. Gradle gives powerful tools to the organization to model standards, often standards on top of the default Jave lifecycle for stuff like auditing, integration testing, different project types, etc. …. An organization can be very rigid with what it imposes onto the developer with Gradle. But this should be the choice of the organization and not of the build tool. As you also pointed out, you can’t have a reasonable single lifecycle for different platforms like Java, Android or C++. They have inherently different lifecycles which should be explicitly modelled to make it easy to work with them.

  12. July 23rd, 2013 at 16:44 | #12

    Hi Nicolas,

    In this post you write about Gradle based on things ‘I’ve heard about Gradle’, but I don’t think you did even a minimal amount of research before making some of these statements. It is frustrating to have to respond to criticism from a position of ignorance.

    All the major positive aspects that distinguish Maven from Ant are present in Gradle. Gradle has stronger declarative power (more than what Maven has to offer), and it provides better capabilities to impose standards.

    Ant also got a few things right that Maven got wrong. This is why some of the most advanced release engineering teams in the industry never switched to Maven, despite Ant’s shortcomings. These teams have recently switched to Gradle (e.g. LinkedIn and Netflix). Large-scale builds demand the capability to deeply integrate custom requirements, and Gradle provides this in a way that Maven will never be able to match – the model is too limited.

    Ask the former build master of Google, the LinkedIn release engineering team, the Netflix release engineering team, the Google Android tooling team, the build infrastructure team of one of the largest financial institutions on the planet who introduced Gradle to a team of 5000 developers whether they consider their delivery process, to quote you, a broken arm or a huge opportunity to increase developer productivity by deeply modeling their workflows within that organization.

    Would you tell enterprise projects that they shouldn’t pay attention to what Spring and Hibernate do because they are frameworks? I don’t get what you are trying to say. Should they just ignore the fact that several major Java projects have switched to Gradle? Sounds like a good strategy for the Maven community – put your fingers in your ears and cover your eyes – pay no attention to industry trends because Maven is just fine.

    I found this a pretty wild posting – arrogance coupled with limited insight. This combination should be a warning sign to people that depend on Maven. I don’t think such posts help to convince people that the Maven community is making coherent arguments. You can go into full rhetoric mode while we’re busy helping more customers switch over to Gradle.

  13. July 23rd, 2013 at 17:13 | #13

    @Yann Le Moigne
    Yann, at least intially when Maven polygot support was added (it was originally available for Maven 2) it was merely lipstick-on-a-pig[1]. The troubles in Maven (as of 2) were decisions/assumptions they made internally. At least then, all you could do with Maven polygot was to express the same information in the same structure just using a different syntax; you still had all the same limitations.

    Disclaimer, I have not looked at all at Maven 3 so I do not know how/if any of those limitations, shortcomings and bad decisions/assumptions from Maven 2.

    [1] https://en.wikipedia.org/wiki/Lipstick_on_a_pig

  14. September 6th, 2013 at 12:04 | #14

    As everyone, you’re obviously free to choose the tool you prefer for the task at hand and there’s nothing wrong with that. Looking forward to that other post of yours, about the “No More Hibernate” page ;-)

  15. nick
    April 10th, 2014 at 21:29 | #15

    It may be very late reply, Lukas Eder goes to JOOQ just like his last comment says :), Steve Ebersole in Hibernate :), Leaving author Nicolas behind. All piece of software is on evolution, people are finding way to make things better and argues what ever they use is better. Gradle is very very good build tool when we compare with other counterparts but its still lacking so many things, hope those things will be addressed by the large community. If we look into this discussion, everyone stating true statements more than egoistic arguments but guys like Lukas and Steve are working with a different development stack all together than the author Nicolas, thats why they have different opinion about the same tool. Real business development (which Nicolas) into will feel about gradle like this no doubt in it, at the same time Framework or API developers like Steve and Lukas will feel gradle is great. I’ve worked in these two stack and i felt the same. As a conclusion there is no gradle, ant, maven or etc… what ever make your life easier go with that. Nicolas please continue your wonderful critics and Steve and Lukas, etc please argue and spread your idea. Thanks to all.

  1. No trackbacks yet.