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?



  • 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!

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
    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.

  16. Sudeera
    July 28th, 2014 at 21:35 | #16

    Gradle is one stupid tool. I tried to use Android Studio (which uses Gradle) and the IDE is nearly unusable because of Gradle. First, you have to wait for 5 minutes for it to download its repos and jars, and if you are not online, you are stuck with nothing. I’d rather hunt for .jar files and write build scripts by hand than using this shitty tool.

  17. JNight
    January 16th, 2015 at 00:43 | #17

    I find basic dependency management difficult in a gradle build because of the way the sub projects are defined. There probably is a way to inherit and override properties, plugin configs, tasks, phases, etc in any particular sub project and also then build from an individual module, not just the root, but its not particularly obvious.

    While maven is more verbose, I’d say its more readable. If I can’t set up a good hierarchy for a larger project then these build files get too redundant. One big root pom to rule them all that may be a pain to maintain but rarely gets touched is better than fighting with a hundred sub project build.gradle files every time I want to change a version of a dependency.

    I want to like it, but I am having trouble getting past the difficulty of doing basic things. I think the flexibility of Gradle forces excessive configuration for the most rudimentary builds. Compile, Test Compile, Run Tests, publish to the local repository…

  18. Joseph
    February 15th, 2015 at 21:53 | #18

    I’m a maven user but the moment I first laid eyes on a build.gradle file I was hooked! After using maven for a long time the syntax still doesn’t make sense to me. I don’t know groovy but the gradle syntax is many times more concise and makes perfect sense. It’s the difference between an old markup language for configuration and a new shiny JVM scripting language with more features than Java(I still like Java better). My biggest issue with gradle is that it’s not as popular as maven. I realize that I’m being shallow and syntax isn’t neccessarily the most imporant feature of a build tool.

  19. Chris
    February 28th, 2015 at 12:29 | #19

    I admit I speak from a position of ignorance with Gradle; but what I can say is this:

    When I first encountered Maven, I was up and running within an hour. Maybe there’s that 10% of projects that it can’t handle well, but for the remaining 90%, it’s damn easy to use.

    After several days of trying to learn Gradle I am still scratching my head about how to organise inter-module dependencies. Perhaps because of it’s power, there doesn’t seem to be any prescribed way of doing things, it’s all very confusing.

  20. Frederick
    March 9th, 2015 at 19:55 | #20

    I agree with Mr. Frankel. I used Ant for years, and all that flexibility caused every build file to be different. I tried Maven 1.x, but it was not until Maven 2.x that the tool and plugin maturity justified the shift. I love Maven’s standard way of laying out a project. It formalized what a directory tree of a project would look like. Developers no longer needed to worry about where the sources or test sources or resources were. Archetypes generated standard project directory trees. Plugins standardized the integration of 3rd party tools and how they can function.

    Unit testing effects the way we architect a project. We design so that we can unit test and mock interfaces and services. We use IoC technologies, like Spring. We are constrained to write testable code. Not a bad thing. In the same way, a structured build tool constrains the way a project is built. If we have a new project type, we need to think about how to fit it into the structure of the standard build system. If it is a whole new technology, such as a form of code generation, we might need to write a plugin, but the plugin should behave the same way as other code generation plugins do, placing output in the standard directories, executing goals in the correct phase.

    Perhaps we can’t blame Gradle for what the Android team did 1-1/2 years ago, but it gives an example of how changing the standards and this extra flexibility can cost thousands, if not tens of thousands of hours of wasted developer time. The Android team changed the directory structure of the Android project. assets/, res/, libs/, and the AndroidManifest.xml would now reside under src/main. They also decided to create an .aar format that did not allow the R classes in it. Instead they included an R.txt properties file, which would then be used to regenerate the R classes for inclusion into your .apk. They also changed where these intermediate files were being generated. These changes caused the Android Maven Plugin team a minimum of 5 months of bugs trying to get it to work right. The Gradle plugin was done first, but you can find many bug reports, complaints on their forums, and in the version control repo.

    IntelliJ may finally be seeing the light at the end of the tunnel with their 14.0.4 EAP release. There are dozens of critical bugs that have been hampering Android developers for ONE AND A HALF YEARS. I speak from experience having wasted a couple of weeks suffering these changes. Sticking to standard directories would have limited the extra code Jetbrains has had to write, just to support Android. Imagine every new tool or technology deciding that they want a different code generation directory, adding new and different phases to handle their new cool R class style code regeneration. IntelliJ has always had limited support for Ant because it was so “flexible”. I’m sure the Jetbrains developers are not nearly as happy with Gradle as is the shiny new toy crowd. They probably realize this could potentially be… just the beginning of the nightmare.

  21. Alex
    July 26th, 2015 at 06:07 | #21

    @Cédridc Champeau

    Ha! try publishing a project with multiple artifacts from gradle to nexus. Gradle barfs when Android’s flavors are used and will simply fail the build. There’s also issues generating javadocs from Gradle on APK projects. POM generate really isn’t that great. Gradle is slower. About 50% slower on a large project. We spent months and months of man hours getting the build ‘right’ with gradle. I just converted it over to maven in about 2 days (80+ modules) and it builds at half the speed. Site generation? practically no support from gradle.

  22. Johnny
    December 4th, 2015 at 21:49 | #22

    Gradle is a pile of shit

  23. Krzysiek
    January 7th, 2016 at 13:30 | #23

    I hate gradle. This is the worst app bulider I ever use. Over and over again I have new problems with gradle.

  24. AnotherJonny
    January 31st, 2016 at 06:18 | #24

    Gradle doesn’t organize library and data files efficiently. A good application always organizes high-read/low-write libraries and resources in a separate place from high read/write data files and meta-data. But Gradle doesn’t seem to distinguish between them and creates many many redundant copies of library files that can be reused if they were properly organized into one place. This makes Gradle unappealing to me because I like to keep high-read/low-write library files on a read-only SSD and high read/write data files on a plain old HDD. This isn’t tenable with Gradle.

  25. Mbah Jadol
    April 8th, 2016 at 19:42 | #25

    In old day i only know java build tools is only ant or the old makefile. Buy for recently i’ve got small project and need to create in java. So for the lazy and stupid like i do, i always look IDE to help my dirty work, and then there is 2 major IDE netbeans and eclipse that i know. That netbeans with gradle included, and eclipse with maven included. After couple day headache i’ve been play with both build tools gradle and maven with my tiny brain, and i have conclude that gradle is more comfort tool for me. And i hope if anyone got the same case like i do, they need to choose gradle to save our day. For real i don’t really like a war between those two build tool fans, because if we think simple as developer our goal is only create some apps, if you a hardcore fan of some of that build tools just use it, for your own good sake.

  26. April 11th, 2016 at 23:55 | #26

    Absolutely agree, great post!

    Somehow every JVM language needs a own build tool. Scala has SBT which is basically a reimplementation of Gradle in Scala. What is the point of rewriting something that already works well in some other language without actually improving anything (actually making it even worse)?

    My experience with Gradle is: The projects that I clone from GitHub are much less likely to compile out-of-the-box compared to Maven projects. The variety of ways of using Gradle that Gradle encourages creates a lot of trouble to understand a new project’s build chain. I mean, I can use this time to create value instead of hacking around and chasing trivial but time consuming configuration issues.

  1. No trackbacks yet.