[HN Gopher] The Problem with Gradle
___________________________________________________________________
The Problem with Gradle
Author : wheresvic4
Score : 175 points
Date : 2021-01-16 13:12 UTC (9 hours ago)
(HTM) web link (www.bruceeckel.com)
(TXT) w3m dump (www.bruceeckel.com)
| jayd16 wrote:
| Can someone explain to me why Gradle is popular? It seems like
| hot garbage even though most teams can make it work.
|
| Maven was painful as well but it felt more consistent to me.
|
| You know whats really sad? MsBuild proj and solution files are
| easier to understand!
|
| I'm sure there's a lot of great work that's going into Gradle but
| I just don't understand why this is the DSL and syntax we decided
| to put effort into.
| gozzoo wrote:
| Because it fixes some of the problems of Maven, which was the
| defacto standard in the Java world, and is quite horrible.
| Gradle is to Maven what svn was to cvs.
| pjmlp wrote:
| What problems? The only one is XML allergy.
| jayd16 wrote:
| I've seen people claim Gradle is language agnostic and
| Maven isn't. Not sure I agree but its what I'm told...
| jdmichal wrote:
| Maven defaults to Java, but I'm pretty sure there's
| compilation plugins for all the JVM languages.
| blktiger wrote:
| Speed - a gradle build computes hashes of all the build
| steps so it knows when to skip things that don't need to be
| run. Spring converted their builds to gradle and were able
| to cut their builds from an hour to 10 minutes (full-ci
| bulds). https://spring.io/blog/2020/06/08/migrating-spring-
| boot-s-bu...
| gozzoo wrote:
| Actually XML is the smaler problem. Maven forces you to use
| a predifened structure for your project. The more some
| project deviates from Maven's assumptions about how it
| should be organized, the more complicated the pom file
| becomes. For each medium sized project I've seen it looks
| completely uncomprehendable. Usually there was only one
| member in the team who can touch it.
| twic wrote:
| Maven is overly rigid.
|
| Years ago, i worked on a project where it made sense to
| have two integration test tasks - main tests and some
| special separate set of tests, i forget why. In Gradle,
| that's trivial. In Maven, it is impossible. You would have
| to write a new plugin which duplicates the existing
| integration test plugin to do it.
|
| Maven runs the stages of the build in a fixed order,
| defined by the plugin code. If you have a reason to run two
| stages in a different order, bad luck, that can't be done.
|
| There are tons of things like this.
| jdmichal wrote:
| I'm pretty sure I've done this before... Maven is
| generally nothing more than some plugin executions with
| default configurations bound to specific phases. Both
| `surefire` and `failsafe` plugins allow you to configure
| the pattern of files executed (via `includes`). So you
| should be able to easily configure three executions, all
| with mutually-exclusive file patterns, one unit-test and
| two integration-tests. And you can choose whether or not
| to bind them to phases or run them manually.
| pjmlp wrote:
| It has Google's Android team as sponsor that has decided to
| push it no matter what, which act as if there was no other
| alternative to Ant available.
|
| Ironically even Google own teams rather use Basel and Soong as
| the Gradle based builds that the Android team imposes to
| everyone else using the Android SDK.
| zmmmmm wrote:
| I reckon the best thing gradle ever did was the 'gradle
| wrapper' which means, if you have just java installed it'll
| bootstrap everything up from nothing. So if starting a new
| project and I just want people to be able to build it and I
| want them to use exactly a specific version of gradle I can
| create a 1 line build file and it works for just about anybody
| who runs it on any platform.
|
| So on the one hand, its the easiest way to get started, and on
| the other hand its a turing complete language so there isn't
| anything it _can 't_ do so once started, people can always keep
| going.
|
| And then, yes, Maven is complex and mysterious in completely
| different ways but almost to the same extent as Gradle.
| wasyl wrote:
| Coming from Gradle, it always baffles me how there's no
| wrapper for every popular tool out there. I'm always confused
| by the venvs, rbenvs, and overall managing multiple versions
| of the toolchain for different projects. In Gradle it's just
| so simple, and with toolchains support [1] it's going to be a
| very predictable build environment with just a simple
| `./gradlew` invocation.
|
| [1] https://docs.gradle.org/current/userguide/toolchains.html
| DrBazza wrote:
| Make is still popular (not necessarily loved), because it still
| largely adheres to the Unix philosophy of doing one thing and one
| thing only. Anything more complex, make it executable and put it
| on the path and then call it from make.
|
| Gradle. It's a full programming language. And let's not forget
| there's a ray tracer in pure cmake doing the rounds.
|
| Being cross-platform without having to drop out of the main build
| tool isn't necessarily a benefit, and that's part of the reason
| for it's complexity.
| zmmmmm wrote:
| What I find fascinating about Gradle is that its utterly
| impossible to say it lacks documentation - go to
| https://docs.gradle.org/current/userguide/userguide.html and see
| the amazing beautiful docs.
|
| But actually learning from those docs is amazingly hard. It's
| like "documentation theater". If you start as a naive user coming
| in, it keeps teasing you that its going to teach you something
| but you just get abstract concept after abstract concept and you
| STILL don't know the mechanics of how a build works. You have to
| kind of reverse engineer the info that Bruce describes out of the
| documentation. Even when you manage to hit actual code examples
| with detailed explanations - they are described in a way that
| fails to give you the generalisable understanding of the
| internals that you need to actually create new things that you
| haven't seen before.
|
| As a developer it generates a distinctly hostile feeling of
| helplessness and powerlessness.
| piva00 wrote:
| Very concise description of my own experience when trying to
| learn Gradle from its docs, frustrating wheel spinning and
| utter confusing to understand from a high level to a detailed
| view.
| pjmlp wrote:
| Android is the only reason I put up with Gradle, for anything
| else Java related, I turn to Maven and happily forget that Gradle
| even exists.
|
| It is Ant all over again, with Groovy slowness and game rig
| hardware requirements to perform in a sane way. There is hardly
| any Android conference without build related performance
| improvement talks.
| bassman9000 wrote:
| Gradle was the excuse ant writers/maintainers wanted not to
| migrate to Maven, because the latter forces you to be cleaner
| with your project organization.
| wasyl wrote:
| > There is hardly any Android conference without build related
| performance improvement talks.
|
| fwiw I think the Android toolchain being slow doesn't help. On
| the same conferences someone will also speak about how the new
| Android Gradle Plugin is X% faster, so it's not all Gradle's
| fault :) That said there's plenty more Gradle can do (and is
| doing) to improve performance. The startup cost to configure
| all tasks is definitely high on my annoyances list
| nsonha wrote:
| Maybe this is a dumb question but I thought gradle kts was
| released a while ago. Why does everyone in this thread still
| complains about groovy? Could they not just use kotlin?
| wasyl wrote:
| It's not an easy switch. Still most of the examples and
| articles are in Groovy. Until recently, IDE (IntelliJ)
| support for Gradle Kotlin DSL was abysmal (like analysing
| stuff on the main thread). Only recently it's getting more
| traction as the worst issues have been resolved.
| pjmlp wrote:
| Because it still is work in progress.
| lazulicurio wrote:
| Reading this, I'm reminded in many (not good) ways of the .NET
| build system. Where trivial projects look simple, but once you
| pull back the curtains there are horrors to behold.
| huodon wrote:
| Kotlin is great, gradle has improved a lot in the past two years,
| especially since it supports .kts scripts, but it's still shit.
| Now, I'm very happy write rust
| jzoch wrote:
| Many have posted about gradle builds forced on them but I've
| found modern Gradle to be quite nice. I don't reach for anything
| too complex - I just list deps and plugins.
|
| Writing new plugins is far easier with Gradle than Maven (and way
| way way less ugly to configure) and there are more plugins
| available (and usually of higher quality than their maven
| counterparts).
|
| Speed is significantly better than Maven. Incremental builds gave
| us back 80% of our time spent sitting on maven. Reusability is
| much better than maven too.
|
| There are definite footguns but if you can avoid them (which I
| understand requires work and itd be better if they were not there
| at all!) then Gradle is decent. Its no Cargo but woe is life. The
| few times I had to parse a file at build time to read some
| credentials in jenkins I've been grateful im using Gradle instead
| of Maven.
| PaulHoule wrote:
| Many people dont appreciate Maven because they get hung up on
| XML. If you need to do anything in Maven which isnt dead easy to
| do in XML you just write a plugin in Java which is the language
| you are coding in anyway.
| Macha wrote:
| I wonder if this is a reflection of enterprise processes.
| Writing a plugin in a previous employer meant creating a new
| repo, a new CI/CD pipeline, getting it pushed to artifactory,
| making sure people had the inhouse artifactory set up in their
| settings.xml, and all that had internal overhead. Also learning
| the maven plugin API. And nobody on your team would want to, so
| you'd be stuck answering every question about this feature
| forever more. Compared to gradle where the same tasks just
| require a few if statements in a scripting language.
| dmitryminkovsky wrote:
| This very much lines up with my experience.
|
| A long time ago I wrote a Maven plugin and decided to clean
| it up for open source. It got absolutely nowhere because
| after everything you describe--setting up a repo; learning
| the Maven API, which is one of those expansive APIs that has
| a lot of metaphoric semantic constructs--distributing it
| involved getting it into Maven Central by which point I had
| run out of time/mental bandwidth and never made it happen.
|
| Compare if I had been using Gradle at the time: I would have
| just coded it up in Groovy, a language I thoroughly enjoy,
| right there in setup. There are some things I don't like
| about Gradle, but there's a lot it has going for it, too.
| Personally, I _like_ XML and enjoy Maven for situations where
| existing plugins are enough--which is 99% of the time--but
| that lack of flexibility can be constraining when existing
| plugins aren 't enough.
| lmm wrote:
| I find that little hurdle actually improves the quality a
| lot. It means people don't write maven plugins for every
| single conceivable scenario; usually there will be at most
| one or two plugins for whatever you wanted to do, properly
| documented and maintained, whereas with gradle there will
| be four or five different plugins with no documentation
| each of which only covers half of the task. And forcing
| people to put logic in actual released plugins rather than
| ad-hoc one-liners in the middle of the build definition
| means you avoid ending up with a bunch of ad-hoc one-liners
| scattered throughout your build definition, which is much
| better for long-term maintenance.
| dmitryminkovsky wrote:
| Yeah for sure, and that's what makes Maven a great tool
| at the end of the day. It's just those instances you
| encounter rarely where existing Maven plugins are not
| enough that I've wished I was using Gradle so I could
| drop a few one-liners and be done with it. I really like
| Groovy so any excuse to write some Groovy is always
| tempting. As you say, a few one liners here and a few one
| liners there can make a build incomprehensible. So people
| need to recognize that and keep their Gradle builds
| approachable if they're going to be doing that. It's pros
| and cons.
| chii wrote:
| if you had made the groovy script in gradle, the
| code/capability would not have been sharable to anyone else
| but this single build (other than copy/paste sharing).
|
| if you had the same code as a maven plugin, it would've
| been instantly sharable, and easily updatable centrally via
| a release process (as maven plugins tend to also be built
| with maven). Upfront work, but for long term reward.
| [deleted]
| happyweasel wrote:
| >Writing a plugin in a previous employer meant creating a new
| >repo [..]
|
| I just used the maven groovy plugin to invoke a groovy script
| containing the functionality instead of a maven plugin (a few
| lines of code). the groovy script was part of the source code
| and therefore easy to tweak. A lot of maven variables from
| the project are accessible from the script. Yeah, it's not
| really nice.
| norswap wrote:
| Maybe so. But there's also a ton of legit criticism of Maven
| for how inflexible it is. Doing any sort of custom task
| requires addons.
|
| Gradle also sucks, but at least you can script it much more
| easily.
| twic wrote:
| > If you need to do anything in Maven [...] you just write a
| plugin
|
| You should not need to write a plugin!
| kstenerud wrote:
| > There are Many Ways to do the Same Thing
|
| This is the crux of the problem, and is a problem with many
| libraries, configuration systems, languages, etc.
|
| The author of said tool wants it to be as widely used as
| possible, so he optimizes for the 100%, going so far up the
| flexibility curve that it becomes incredibly difficult to do 80%
| of the things you want.
|
| What these authors should be doing is optimizing for the 80%,
| which means an opinionated top layer that offers a single way to
| do everything that 80% of your users would want to do. Then if
| you're smart, you'll have a layered architecture (which the 80%
| layer rests upon) that allows the other 20% to learn about how
| the sausage is made in order to do their complex tasks.
|
| With this, you have a common tool that is at least 80% easily
| understandable with minimal time investment.
|
| Failure to do this gives you unfriendly systems like CMake,
| Gradle, OpenSSL, Postfix, and Java's time libraries.
|
| U/X applies to code as well.
| adamc wrote:
| This is a nugget of great wisdom. (I will likely get downvoted
| for such a useless comment... so be it.)
|
| Trying to do everything for everyone makes for very complex
| systems that are too abstract to be easily used.
| octopoc wrote:
| > What these authors should be doing is optimizing for the 80%,
| which means an opinionated top layer that offers a single way
| to do everything that 80% of your users would want to do. Then
| if you're smart, you'll have a layered architecture (which the
| 80% layer rests upon) that allows the other 20% to learn about
| how the sausage is made in order to do their complex tasks.
|
| A good example of this approach is MSBuild + Nuke [1]. You can
| have as much complexity as you want in your Nuke build script
| (which is plain C# in a normal, debuggable C# project), but
| MSBuild has to exist to bootstrap the Nuke build script.
|
| [1] http://www.nuke.build/
| dlandis wrote:
| I wonder though, how much is some extra complexity good for the
| bottom line of companies that make their money on consulting
| and supporting the tools that they create/maintain?
| vips7L wrote:
| What's wrong with java.time.* ? I've never found it to be hard
| to grasp.
| cesarb wrote:
| The java.time.* are the new classes (IIRC, based on joda-
| time), but there are also the old time libraries in
| java.util.* and java.text.*. I don't know which ones the
| parent poster was talking about, but it might be the old
| ones.
| vips7L wrote:
| Yes I know they're "new", but the Java time API was
| released 7 years ago with JDK 8. I don't think its fair to
| be critical of something that was fixed almost a decade
| ago.
| charrondev wrote:
| Unfortunately a lot of people don't have access to Java 8
| on the largest customer facing Java platform (android).
|
| The java.time libraries are available on android starting
| API level 26 https://developer.android.com/reference/java
| /time/package-su...
|
| That is android 11, released in September of 2020 which
| is not widely distributed.
|
| Does anyone know why the delay? It looks like Java 8
| language features finally became compatible through some
| compatibility layer in Gradle 4.
|
| Was it because of the lawsuits?
| ohgodplsno wrote:
| Basically, yes. Google has been awfully slow at
| implementing some Java 8+ features. Their current
| solution is D8 desugaring, which basically rewites all
| the APIs into JDK8 compatible code.
| EddieRingle wrote:
| This is incorrect. You can use APIs like java.time on any
| version by using desugaring: https://developer.android.co
| m/studio/write/java8-support#lib...
| vips7L wrote:
| Personally, I don't consider Android to be Java and I am
| quite happy that Google is pushing Kotlin now instead.
| szatkus wrote:
| The problem is that many Java projects in the wild are...
| well, old. Some of them haven't migrated to Java 8 yet
| and even then you can stuck with a lot of code using the
| old API.
| sn41 wrote:
| "Simple things should be simple, complex things should be
| possible" - Alan Kay.
|
| Instead, in overthought out systems, complex things are simple,
| and simple things are possible with unnecessary effort.
| Cwizard wrote:
| I agree. When I was a kid I had a camera that had an 'easy
| mode' in software. If you turned it on, the software would
| disable most advanced features and the UI would be something
| incredibly simple. This allowed me a complete novice to get
| started taking pictures. After some experience I turned the
| setting off and started to experiment with more advanced
| features without getting overwhelmed. I always wondered why not
| more products adopted this type of UX.
| chr wrote:
| Also nice how the built-in Iphone calculator app is plain and
| simple in portrait mode, and rivals a scientific calculator
| when rotated to landscape mode.
| Tomte wrote:
| The problem is that this is only discoverable by accident
| in specific circumstances.
|
| I almost never hold my phone in landscape.
| vosper wrote:
| Apple did the same thing with undo. Such a commonly used
| feature, hidden behind shaking your phone? That's not
| even an interaction. They've slightly improved it with
| three-finger swipe to the side, which at least is a bit
| like a gesture, but again completely undiscoverable.
| Apparently under no circumstances will we just be getting
| an undo button.
|
| It's not just Apple, though: there's a whole page of
| useful settings for Instagram's Hyperlapse app. Guess how
| you open it? You tap the screen four times with four
| fingers. Why on earth did they build and maintain a
| settings page and then hide it like that?
| nmfisher wrote:
| You just blew my mind.
| layer8 wrote:
| It should go RPN when holding the phone upside down. ;)
| tjalfi wrote:
| Raymond Chen, a Microsoft blogger, has posted[0] about why
| Windows doesn't use an expert mode.
|
| [0] https://devblogs.microsoft.com/oldnewthing/20030728-00/?p
| =43...
| Hallucinaut wrote:
| They do kinds of have an Expert mode though; all of the
| original menus and options that they hide behind
| frustratingly glib, to the point of being useless, "modern"
| menus, with plenty of whitespace.
|
| A recent Windows update even went so far as to proudly
| boast about how they were adding back menu items that had
| disappeared in this drive for stupidification of the menus.
| Hardly progress.
| szatkus wrote:
| It's an old post, they have in Windows 10. Kinda. Many
| sections in Settings have options for advanced settings
| that would take you to the old Control Panel.
| not_knuth wrote:
| I think what you are referring to is called a Turing Tarpit
| [0].
|
| [0] https://en.wikipedia.org/wiki/Turing_tarpit
| cataphract wrote:
| The article seems to boil to down to: you need to understand
| Groovy to effectively use Gradle.
|
| It's impossible to disagree with this, but this is a realization
| you should have after interacting with it after 10 minutes.
|
| I may be biased because I'd been using Groovy (Grails apps) for
| years before I used Gradle so the syntax was not a problem at all
| for me. For me, the problem with Gradle is the very poor
| documentation. If I want to do something more complex, I either
| find the answer in Stackoverflow/the Gradle message board, or I
| will have to look at the source code of the plugins. Creating a
| task for scratch is fairly simple, it's interacting with the
| plugins that's difficult, and while I agree with the author that
| excessive abstraction through DSLs doesn't help, if these DSLs
| didn't leak and were properly documented it wouldn't be a
| problem.
|
| Another problem is that it's clear what the right conventions
| are. Say you want some classes to some exec task. Where should
| these classes live? Do you use a configuration? Create a
| sourceSet? Add a directory to an existing sourceSet? You just
| edit the classpath property in the task to point to a directory?
| I miss some of the rigidity of Maven, though not its XML syntax.
| The ability to write actual functions in Groovy (e.g. a closure
| implementing a file filter) is very much welcome.
| emsy wrote:
| Having used Gradle, I disagree. Even if you know Groovy,
| declarations in Gradle are executed in a certain order and you
| don't really know what a closure does or what it's side effects
| are. Sometimes you have to read the source code because the
| documentation is insufficient. Gradle is not a simple tool and
| the documentation (last time I was using it) isn't helping.
| cataphract wrote:
| I agree that order of execution is sometimes problematic in
| Groovy and you have to use evaluationDependsOn() or
| afterEvaluate {}. I don't think the DSLs are per se
| particularly problematic; they generally just set some
| properties of the task (when they're more complex and yet the
| abstraction leaks, then they do more harm than do). But yes,
| the documentation is awful, and is IMO the biggest problem
| with Gradle.
| acaloiar wrote:
| While I agree with you that it should be obvious that Groovy
| knowledge is necessary to operate Gradle, I think it's
| important to note that the intersect between people building
| things in Groovy and people building things in Java/Kotlin is
| quite small. And for that reason Gradle, with Groovy as its
| star feature, will always be a fraught choice for a build
| system.
|
| Developers simply have to know too much Groovy to operate
| Gradle effectively.
| twic wrote:
| I entirely agree. But i also don't know what the Gradle
| authors could have done instead. Writing build scripts in
| Java 1.6 (the latest version at the time Gradle was written)
| would have been a showstopper. Kotlin didn't exist. XML alone
| isn't expressive enough, so you would have needed some sort
| of Ant-like crummy language expressed in XML.
|
| Buildr, which i think predated Gradle, used Ruby. I'm not
| sure Ruby is any better than Groovy here.
|
| Perhaps Jython would have been a good choice.
| emsy wrote:
| The problems match my experience with Gradle pretty well, and
| they point to a bigger issue in build systems: you usually can't
| easily debug the build system. Most build systems try to be
| declarative, but can't help to have imperative parts where order
| of execution matters or when a certain environment variable is
| set. You have these kind of problems in Gradle and I experienced
| them in Cmake, Maven and Make as well. At some point you just
| want to step-debug or have the environment variables print at a
| certain point during the build. All I want is a build tool where
| I declare my build by simply calling functions (or extend with
| custom functions) and if there's an issue I want to be able to
| step through the script and check what's wrong.
| cataphract wrote:
| You very much can debug Gradle. It's just like any other
| Java/Groovy application. You set a breakpoint in the build file
| or some Gradle source file and you attach a debugger. In this
| respect, it's probably more debug-friendly than, say Makefiles
| where all you can do is add some print statements or go through
| megabytes of debug output.
| wasyl wrote:
| Adding to that, in IntelliJ it's as simple as running the
| task from the 'run Gradle task' window (not sure how it's
| called) with Shift pressed. All the breakpoints in the build
| scripts will now work.
|
| If you also use wrapper with sources (`-all` instead of
| `-bin` suffix in the `gradle/wrapper/gradle-
| wrapper.properties`) you can step into the entire Gradle
| source code as well
| zestyping wrote:
| I found these to be huge stumbling blocks:
|
| - Scoping is mysterious: things that you expect to be in scope
| AREN'T, and lots of things that you can't see ARE in scope. This
| makes it impossible for a beginner to look up the source code (or
| even, often, the documentation) that corresponds to a given thing
| in a Gradle file: you might realize that "ext" exists, but
| there's no way to tell what scope it comes from. That defeats
| most of the usual approaches that programmers have learned for
| exploring a new system. To use the UX lingo, Gradle is
| undiscoverable.
|
| - Similarly, your Gradle script is interacting with things you
| can't see. When you write "sourceSets { ... }" you're actually
| calling a method on an object. What object? You can't see it, or
| even a reference to it, in your Gradle file.
|
| - I came to Gradle with the definition in my head that a build
| tool is a thing that tracks dependencies so that it only has to
| rebuild things whose inputs have changed. Gradle doesn't do that
| at all. Many hours of searching for how Gradle detects changes
| were fruitless, because it doesn't even try, really. Gradle
| basically always runs everything, which is why it's so goddamn
| slow. This is because the entire dependency graph is constructed
| dynamically on every run, and that prevents the system from
| effectively retaining from run to run which steps have already
| been done.
| larusso wrote:
| As others mentioned gradle has a build cache. It works
| different to make as it doesn't take the mime timestamp of the
| input/output but rather creates hashes. In the early versions
| these caches were project local only. Later the cache was
| system wide. Now you can setup a gradle cache-server so the
| whole team can use the same cache. But this all comes of course
| with some restrictions. Gradle needs full control over the
| inputs/outputs. If another tool makes a change to an output
| gradle will mark this as dirty and will rebuild it from
| scratch. Same when you update java, gradle or plugins since
| gradle can't be certain that a an update of the mentioned parts
| would result in a different output. On paper this all makes
| sense. But if you start to write custom tasks which depend on
| each other or work on lists of input files this becomes
| increasingly difficult. Luckily writing tests for custom tasks
| is easy if one finds the documentation and muse to set this up.
| mumblemumble wrote:
| I am beginning to think that a lot of these problems stem from
| Gradle's frameworkyness. You don't call it, it calls you.
| Whatever it's doing in between when it calls into the bits and
| pieces of code that you wrote is a mystery. That, in turn,
| makes it almost impossible to intuit how things in a Gradle
| script relate to each other. The relationships aren't lexical,
| and you can't figure out how things work by tracing through the
| code. Instead, its inner workings feel like spooky action at a
| distance.
|
| If Gradle were more of a library, and a Gradle build script
| were just a Groovy or Kotlin script that calls into that
| library, everything might be easier to understand.
| jicea wrote:
| > Many hours of searching for how Gradle detects changes were
| fruitless, because it doesn't even try, really. Gradle
| basically always runs everything, which is why it's so goddamn
| slow. This is because the entire dependency graph is
| constructed dynamically on every run,
|
| Something that is not clear from the Gradle documentation is
| that every task must have its input and output defined
| (inputFile, inputDirectory, outputFile, outputDitectory
| property). It is absolutely essential so Gradle can infer which
| task has to be rerun when, for instance, a build is run. This
| is usually done for the 'basic' task (like build, test etc..)
| but you have to specify it when you have custom task. This can
| really make a difference in speed. Another trick is to use the
| console option (gradle build --console plain) so you will see
| each task that have been run and their status (if they have be
| runned, or if they have been skipped due to dependencies)
| p2detar wrote:
| > I came to Gradle with the definition in my head that a build
| tool is a thing that tracks dependencies so that it only has to
| rebuild things whose inputs have changed. Gradle doesn't do
| that at all. Many hours of searching for how Gradle detects
| changes were fruitless, because it doesn't even try, really.
| Gradle basically always runs everything, which is why it's so
| goddamn slow.
|
| Gradle has build cache since version 3.5 [0]. You probably mean
| the configuration phase for which caching was introduced in
| version 6.6. [1]
|
| Gradle has been consistently improving the last couple of
| years. I'm quite happy with its speed since the v6.5 upgrade.
|
| 0 - https://docs.gradle.org/current/userguide/build_cache.html
|
| 1 - https://docs.gradle.org/6.6/release-notes.html
| wasyl wrote:
| > Scoping is mysterious
|
| It definitely is confusing, but while the rules to scoping are
| pretty extensive, they're also well defined. The trick is to
| know how Gradle "travels" through objects and looks for the
| property in class properties, extensions, extras, etc. I wrote
| about it [1] if you're interested.
|
| > Gradle script is interacting with things you can't see
|
| Not necessarily -- yes, the receiver for top-level calls
| (Project instance) is implicit, but you can access it via
| `project` property. You could prefix each top-level call in
| your Gradle script with `project.`, making all calls explicit.
|
| Btw `sourceSets { }` calls the lambda on a `SourceSetContainer`
| instance, accessible via `Project#sourceSets` property [2], so
| you can get an instance of it. I suppose there might some
| objects that are configurable but not accessible, but nothing
| comes to my mind right away, actually.
|
| > a build tool is a thing that tracks dependencies so that it
| only has to rebuild things whose inputs have changed. Gradle
| doesn't do that at all.
|
| You might've had a bad experience with a misconfigured
| plugin/build or a bug. Gradle does track dependencies, and
| while it doesn't do that perfectly always, it avoids a lot of
| unnecessary work, on many layers (incremental compilation, task
| avoidance, task caching). As a general rule, when running the
| same task(s) twice, the second invocation shouldn't execute any
| taks.
|
| > This is because the entire dependency graph is constructed
| dynamically on every run It's true that configuration/task
| graph creation is still happening on every invocation (this
| will change with Configuration Cache [3]). But it's definitely
| not accurate that this prevents Gradle from knowing which steps
| have already been done. Again, I fully believe it didn't work
| for you, but it doesn't mean Gradle doesn't do that.
|
| I'm not trying to say Gradle doesn't have flaws. In fact, I
| think your comment proves the points from the article. Unless
| one invests in learning how Gradle works, it's impossible to
| spot e.g. why the build isn't doing any task avoidance, or
| understand scoping. It's rather unfortunate, because after that
| initial investment Gradle is a pretty great tool to work with.
|
| [1] https://medium.com/tooploox/where-do-gradle-properties-
| come-... [2]
| https://docs.gradle.org/current/dsl/org.gradle.api.Project.h...
| [3]
| https://docs.gradle.org/current/userguide/configuration_cach...
| irateswami wrote:
| I'm so glad I don't have to deal with Java and it's ecosystem
| anymore.
| pjmlp wrote:
| Luckily it is possible to be happy in Java ecosystem without
| touching anything Gradle related, unless one needs to deal with
| Android.
|
| That is my path to happiness, Netbeans | Eclipse + Maven.
| strulovich wrote:
| If you work on any seriously big Java/Kotlin/Android project, and
| value your time, I recommend looking at Buck (or Bazel or other
| tools) for building instead of Gradle if you haven't done so yet.
|
| It would be annoying to move build tools, and plenty more of
| hookups are not as convenient in a bunch if cases, but when you
| get it going things will run faster. (So again, the bigger the
| project, the more likely you would like that)
|
| A big part of the reason is that tools suck as Buck (which, like
| Bazel, uses Skylark as the language, which is a very limited
| python in essence) avoid the general programming patterns to
| avoid the issues described here.
| anuragsoni wrote:
| I concur. I worked on a java project at a previous job and
| Bazel was instrumental in getting fast deterministic builds.
| There were some growing pains as the bazel docs weren't great
| back then (this was before bazel reached 1.0), but once we got
| things to work it was nice to work with. We were able to
| leverage Bazel for our Angular application as well so it was
| nice to have everything building with one tool.
|
| > A big part of the reason is that tools suck as Buck (which,
| like Bazel, uses Skylark as the language, which is a very
| limited python in essence) avoid the general programming
| patterns to avoid the issues described here.
|
| I also agree with this. My current language of choice is OCaml
| and the most popular build tool is dune [1], which uses an
| s-expression based configuration language, and its nice to have
| a more restrictive DSL that avoids some pitfalls of using a
| full blown programming language for configuring builds.
|
| [1] https://dune.build/
| cmckn wrote:
| Accomplishing what I thought were standard tasks with Gradle
| always felt like fragile hacks. The nature of being a younger
| build system with more API evolution means there are at least 3
| ways to do something, without good explanation, and they often
| can't be mixed. Maven feels like a build system that I'm
| configuring. Gradle feels like a piece of software that I'm
| developing to build my project.
|
| I will say, Gradles files and console output is usually easier on
| the eyes. And Maven seems to needlessly re-build things when
| Gradle does not. Still, I want to fiddle with my project, not my
| build scripts.
| pcw888 wrote:
| I'm surpised to see such negative comments. I really enjoy using
| it - for a build tool that says a lot.
| freedomben wrote:
| A bit of a side note here regarding the author.
|
| Bruce Eckel's book "Thinking in C++ Vols 1 and 2"[1][2] was
| possibly my favorite book ever read. Bruce is (in my personal
| opinion as an observer of people with zero professional training
| in psychology) a depth-first learner and naturally seeks to
| understand how things work by looking at the layers. Building up
| from there allows true understanding and even mastery of the
| material.
|
| This is exactly how I am as well, and the result is often that it
| can take a while for me to pick things up and really understand
| them (since I have to cover so much more material than a typical
| person) but my level of mastery afterward is typically very high.
|
| My experience now from well over a decade in the industry is that
| most people are not this way, and also that many people who _are_
| this way _don 't necessarily realize it_. If you feel like
| understanding history, layers, etc helps you understand things
| much better, do yourself a favor and follow Bruce Eckel's blog
| and read his books. Thinking in C++ 2nd edition is 20 years old
| now. A third edition would be wonderful. Or maybe even better,
| "Thinking in Rust" :-D
|
| [1] Volume 1 available for free on Archive.org:
| https://archive.org/details/TICPP2ndEdVolOne
|
| [2] Volume 2 available for free on Archive.org:
| https://archive.org/details/TICPP2ndEdVolTwo
| Tainnor wrote:
| Interesting observation. I feel like I am like that - I hate
| doing anything that requires me to develop only a superficial
| understanding (e.g. messing around with Kubernetes
| configuration without understanding how it all works on a
| fundamental level). I also don't like systems that are hard to
| debug - I want to be able to make assumptions and test them,
| and that can sometimes be notoriously difficult with cloud-
| based infrastructure.
| freedomben wrote:
| Interesting you mention K8s, I had that same problem! It took
| me 6 months to get up to speed on K8s because I wanted to
| what everything meant, and those are all deep rabbit holes
| (like, try explaining the `apiVersion` in every object
| without going down a rabbit hole of how K8s works for
| example).
|
| Making that even worse there wasn't much out there to cover
| internals. The situation is much better now though. I guess
| that's part of price you pay to be an early adopter of the
| latest hotness.
| Tainnor wrote:
| I still don't really know how Kubernetes works deep down,
| although I have learned enough to at least debug some of
| the most common issues I encounter at work, so if you have
| any very good resources (don't have to be free), I'd be
| happy to hear of them (the resources I've tried weren't
| very good, unfortunately).
| coding123 wrote:
| If I had to go back to Java tomorrow I would use Gradle hands
| down. I don't know why the author didn't grok it too well, but
| for me it has tons of plugins, the scriptability when a plugin is
| slightly off from what you need, and can be extremely tiny when
| you just need to build a simple jar.
| motoboi wrote:
| One thing caught my attention on this site: where is the
| scrollbar (safari iPhone)?
| jlund-molfese wrote:
| It's still there, it's just white instead of grey. Which works
| fine with the header, but disappears as you scroll.
| vbezhenar wrote:
| When someone does not understand basic tool which is used by most
| Java developers and that person writes book on that language,
| that's makes me very surprised. Obviously that person does not
| have any practical experience with Java, because there's no way
| you wouldn't stumble onto Gradle or Maven if you're writing real
| world code in Java.
|
| I guess, that book writing skill is more important in writing
| good books, than programming skill.
| siva7 wrote:
| I think you might have issues comprehending what the Author is
| talking about or the history of maven/gradle.
| sorokod wrote:
| The person is Bruce Eckel, you may want to lookup his
| credentials.
| [deleted]
| 0x445442 wrote:
| Or, if someone like Bruce Eckel has these observations it may
| be time to take a step back and listen.
| draw_down wrote:
| > Commands are indented (horribly, by tabs, because make was
| created in the early days of Unix when they were still obsessed
| with saving bytes)
|
| See, to me this is exactly not simple (a reference to make's
| "simplicity" appears shortly after this). It's a form of
| complexity because every time something is wrong with the build,
| this is one of the things I will need to check.
|
| Moving the complexity elsewhere so that it becomes someone else's
| problem just does not work for me as a definition of simplicity.
| You see this pattern a lot. Golang is pretty much an entire
| object lesson in this dynamic. Everything is "simple", aka, "your
| problem".
| ncmncm wrote:
| The problem with Gradle is that people try to use it, and so try
| to understand it, and then treat the sunk cost to understand it
| as a reason to keep using it. Bruce correctly sees being locked
| into Gradle as a way to need his expertise, but that is not a
| reason to follow him down the rabbit hole.
|
| The correct response to discovering the nature of Gradle is to
| abandon it, immediately. (Similarly Waf, and Scons.) The world
| does not need yet another one-or-two-language-target build
| system, or another build system as full general scripting
| language. Things work better when you don't need expertise. A
| build system should be just _barely_ powerful enough to do
| builds, but not powerful enough to mystify. A build system should
| work equally well for all the languages you might find you need
| to use. A build system should not need to be studied to be
| understood: isolated examples should suffice for each need.
|
| Similarly, the build for a project should not need to be
| understood: everything you need to know about what you are
| looking at should be right there, or (failing that) in a single,
| central place for the project. The build should be the _least_
| interesting or engaging part of the project; the project itself
| inevitably demands more attention than you can spare. A build
| system that demands attention is a child screaming when you need
| to work.
| huodon wrote:
| I agree with you very much. Since gradle supported kotlin
| script(typed), I seem to have a little understanding of it. I
| have used it for a long time. Besides the treat the sunk cost,
| Maven makes people less willing to use it than gradle.
| therealdrag0 wrote:
| A lot of the complains here remind me of SBT. Makes me dearly mis
| Maven. I have had a lot of fights with maven, but at least the
| XML schemas are straightforward. Also strangely all my teams SBT
| project configs are full of red-underlines in IntelliJ even
| though they work fine...
| misja111 wrote:
| +1. SBT is a lot like Gradle but worse. Funny anecdote: SBT
| originally stood for 'simple build tool'. At some point this
| was changed to 'Scala build tool' and I can fully understand
| why ..
| nucatus wrote:
| all you need to know about gradle is that there are two phases:
| configuration and execution. Everything else are details :)
| twic wrote:
| It took me months of working with Gradle before this clicked,
| but once it did, everything seemed far simpler.
| stunt wrote:
| Both Maven and Gradle suffer from bad user/developer experience.
| I think it's partly due to the culture and mindset that Java
| dictates to its ecosystem. The languages determines our
| experience, and the experience influences the culture.
| 0x445442 wrote:
| Yeah, I've never used the combination professionally but Any
| wity Ivy always struck me as the happy zone. Although, over
| time, Maven's lack of explicit flow control has bothered me
| less and less.
| habosa wrote:
| Gradle was designed on such shaky foundations, namely Groovy.
| Let's make build files in an unpopular scripting language with
| limited tooling ... what could go wrong!
|
| I despise it. XML seemed bad when we had Maven but at least it
| was a markup language.
| grandinj wrote:
| And when gradle fails (which is frequent) your debugging
| abilities are extremely limited.
|
| For example, someone "donated" a gradle build script to an open
| source project I help maintain. It lasted less than 6 months
| before it began breaking, not because we changed stuff, but
| because gradle updates had changed how some things worked and a
| plug-in stopped working. Now "obviously" the answer is that we
| should have pegged the version of gradle required to use the
| script, but (a) I don't even know if that's possible (b) the
| donator definitely didn't think to do that (c) who changes such
| things in such a production level tool during a stable release
| cycle?
|
| Now the gradle people certainly seem decent, in my interactions
| with them, but I think there is unfortunately a strong case of
| Stockholm Syndrome going on there.
| pbourke wrote:
| > Now "obviously" the answer is that we should have pegged the
| version of gradle required to use the script
|
| My first step with either gradle or maven is to install the
| wrapper generator, which has this effect. After adding the
| wrapper you invoke it via ./gradlew or ./mvnw in the project
| directory. The version of gradle or maven is then pinned until
| manually updated.
|
| It's not perfect - especially in terms of IDE support - but
| it's crucial for keeping your CLI builds consistent across team
| members and in automation.
|
| gradle wrapper:
| https://docs.gradle.org/current/userguide/gradle_wrapper.htm...
|
| maven wrapper: https://github.com/takari/maven-wrapper
| koolba wrote:
| > This is the problem I had with Gradle:
|
| > _To do anything you have to know everything_
|
| This sums it up pretty well. Coming from a background of using
| Maven purely for dependency management and basic compilation,
| existing Gradle projects are incredibly unapproachable and slow.
| And don't get me started on the background daemons to speed
| things up either.
| mrec wrote:
| Yup. Gradle is by far the worst-designed technology I've
| encountered in ~30 years of programming. Using it not only made
| me not want to use Gradle, it made me not want to use Java.
| allenbrunson wrote:
| hard agree.
|
| i took up flutter a couple of years ago, which means i am now
| saddled with (ugh) _gradle_ for android builds. i am used to
| being able to intuit the underlying architecture of various
| tech things and fix them, which is utterly impossible as far
| as gradle goes.
|
| not only are the error messages unhelpful, they are usually
| confidently incorrect. they tell you the problem is likely
| thing X, which in fact has nothing to do with the problem.
| (to be fair, this seems to be coming from whatever stuff
| google has added to the android build process, rather than
| gradle itself.)
|
| these days, once gradle starts spitting errors, i know better
| than to read them. instead, i have to start thinking about
| when the build last worked, and what might have changed. if
| that path proves not to bear fruit, then it is time to trash
| that project completely and recreate it from scratch, which
| experience has taught me will take a lot less time than
| trying to "fix" the gradle build errors.
| atc wrote:
| I second this. Java's paid the bills for most of my career
| (17 years) and it is second only to NPM and its ecosystem in
| my book.
|
| Compared to Cargo (Rust) and Cabal or Stack in Haskell, it's
| constantly painful to use.
| eplanit wrote:
| Exactly. And now, android development is by design impossible
| without it. So stupid.
| usrusr wrote:
| > Gradle is by far the worst-designed technology I've
| encountered in ~30 years of programming.
|
| I nominate Groovy. Many of gradle's failures are just
| idiomatic groovy. The entire mindset of "friendly
| simplifications" that work 80% of the time, and if they give
| pretend that you don't notice, look, there's pretty code over
| there!
|
| Even kotlin suffers from some of that (you can override a val
| x:Int with a val x:Int get() unless it's tied down otherwise,
| talk about principle of maximum surprise) but the genes from
| the other parent avoid the worst.
| mrec wrote:
| I think I conflate the two, and I'm not sure that's wrong.
| I've never seen anyone use Groovy outside Gradle. I mean
| why would you, if you had a choice?
| tamasnet wrote:
| Groovy is fantastic for quickly creating domain specific
| languages. I've done a bunch of them over the years for
| different problem domains and have yet to find another
| solution that yields effective custom languages that are
| as readable and easy to implement.
| imtringued wrote:
| There are worse things than using Grails. For example
| using straight up Spring. Grails is a sane wrapper around
| Spring so you can easily bring regular Java developers
| into a sane ecosystem. For example Grails' Gorm is the
| only sane way of using Hibernate in the entire JVM
| ecosystem. Using Hibernate directly will drain your
| sanity very quickly.
| McP wrote:
| I've had to use it to configure Jenkins. In Groovy,
| variables are global if you forget to declare them with
| 'var'. This has caused so many concurrency bugs and so
| much sadness.
| Tainnor wrote:
| Back in the days when Kotlin didn't exist and even Scala
| was in its infancy, some people genuinely liked the JVM
| ecosystem and even aspects of Java itself, but were
| turned off by the verbosity of Java. Those were the
| people that started using Groovy and also projects such
| as Grails (especially since they saw the success of Rails
| and Django and wanted to emulate that).
|
| Also, I guess some people genuinely like gradual typing,
| although I've never found much use for it.
|
| Nowadays, I wouldn't pick up Groovy anymore, but there
| was a time where it was basically that, or Java (or a
| different ecosystem entirely; or something like JRuby /
| Jython).
| zmmmmm wrote:
| Groovy is an amazing language. Don't judge it based on
| Gradle. It is used for all kinds of things. Gradle sort
| of interacts with it in a highly toxic way and brings out
| all its bad parts. If you use it the opposite way - as a
| better version of Java with mostly structured code,
| plenty of explicit typing and avoiding the highly "magic"
| aspects that Gradle focuses on, then its a great language
| for application development. Certainly better for high
| level things than Java - but completely 100% compatible
| with the Java ecosystem.
| cataphract wrote:
| Especially before Java 8, writing Java code was very
| painful compared with Groovy, even though Groovy was
| fairly slower, and its compiler buggy. Groovy has
| closures, AST transformations builtin, much nicer syntax
| for properties (backed by getters/setters), ability to
| sort-of change classes at runtime (without
| instrumentation), multiple dispatch (i.e. dispatch based
| on the runtime type of the arguments), the ability to use
| reflection without the awful reflection API and so on.
| michaelcampbell wrote:
| I have an old java (7, 8) app I maintain that whenever
| possible I move classes to Groovy as I am making other
| changes in them.
|
| I would probably do Kotlin, now, but that wasn't an
| option when I started this.
|
| The amount of boilerplate removed is one big win, but
| moreover the more functionally oriented aspects of most
| anything you'd do with a for-loop in java is wonderful.
|
| And with annotations such as @CompileStatic and
| @TypeChecked, I am able to forgo SOME of the syntactic
| niceties for the compile-time binding java-comparable
| speed.
| EE84M3i wrote:
| >you can override a val x:Int with a val x:Int get()
|
| Could you expand on this? I don't follow what you mean. Are
| you talking about some form of shadowing?
| EddieRingle wrote:
| They're confusing a read-only property that can be
| overridden with one that's made final.
| usrusr wrote:
| Kotlin is playing it fast and loose with blurring the
| line between fields and bean-style properties. In Java
| you could have a public final field and it was obvious
| that it was immutable (unless referencing a mutable
| object). Kotlin, in an attempt to match Groovy in syntax
| cuteness, allows to declare a val (supposedly the
| equivalent of a java final field) that is actually not
| backed by memory at all but a getter method in disguise.
| val x: Int // this is an immutable value val y: Int
| // this is an immutable Function0<Int> that is executed
| each time and but pretends to be a val get() =
| System.currentTimeMillis()
| ptx wrote:
| C# also does this, and so do Python, JavaScript and
| Visual Basic. Java is the odd one out by not supporting
| properties.
| rcoveson wrote:
| Can anybody explain to me why it ever seemed like a good
| idea to make both: (1) Semicolons at the ends of lines and
| (2) Function-call parentheses, not _required_ , and not
| _illegal_ , but _optional_? It strikes me as an abdication
| of the responsibility of a designer, like making both
| String::substring and String::substr available as aliases
| one to the other. Who cares? Choose one and stick with it!
| Otherwise it becomes a race between linter-writers and
| community programmers to see if the entire ecosystem will
| become polluted with an ugly mix of both styles. A race
| which the linter-writers always lose.
| zmmmmm wrote:
| Groovy was created during the time when Ruby was taking
| off and was dramatically improving productivity of
| creating basic CRUD type web sites. So Ruby had a
| beautiful simple syntax, and I think Groovy was an
| experiment to see how close you could get to that while
| maintaining compatibility with Java syntax. It's actually
| a remarkable success as far as it goes - most Java code
| can be copy and pasted in and is valid Groovy. But of
| course it only works because it optionally accepts
| parentheses, explicit vs implicit arguments etc.
|
| It does lead though to one of the biggest lies which is
| "if you know Java then you already know Groovy!" - that's
| just a mean trick to play on people.
| cmehdy wrote:
| Writing Groovy scripts in JMeter (for some custom requests)
| when doing distributed performance testing was a good way
| to enjoy pretty much anything else afterwards.
|
| I suppose I should more accurately call that thing JSR223 +
| Groovy, all stored in an extensive XML file and edited
| through the JMeter UI..
| p2detar wrote:
| Sorry that you feel this way, but this is simply not true. If
| it were the case, why would all these companies [0] waste
| their time with Gradle? Bad technologies tend do die out. Not
| the case here.
|
| 0 - https://gradle.com/customers
|
| (Edit: Heh, TIL rage downvotes are a thing in HN as well.)
| TheRealSteel wrote:
| I don't understand why Gradle breaks every second time I
| build my project, and I have to run Clean Project.
|
| If Clean Project is required to build the project, why isn't
| that part of the build process?
| rwoerz wrote:
| Same for Maven. Common reason: the mere presence of a
| "leftover after refactoring" file beneath target/ breaks
| the build because it is still included in the classpath.
| eitland wrote:
| FWIW: I've used Maven for years and I don't have these
| problems.
|
| When I am tasked with fixong other peoples config I
| usually move things to the correct location, delete the
| corresponding configuration qnd then everything works
| (better).
| kohlerm wrote:
| Come on. Gradle might have many features you might not need,
| but IMHO the one popular alternative maven is one of the
| worst designed build tools. Dependency resolution is a joke
| just taking the shortest path in the tree in case of
| conflicts. No good support for incremental compiles etc
| bitcharmer wrote:
| I have the same impression of gradle. If I have to learn
| another language (groovy) and a whole new platform
| infrastructure and APIs just to understand what a build does,
| it's definitely not worth the effort. Most of my peers have the
| same views.
|
| Fun fact: look up gradle in urban dictionary.
| zmmmmm wrote:
| This argument I don't really get. You're going to learn a
| "language" anyway - whatever build system you employ. It may
| or may not be Turing complete, but you're going to end up
| learning it once you get to any level of complexity in what
| you are doing.
|
| Why not have it be something with more general usefulness as
| well?
| posedge wrote:
| Yeah about that, do you have some insight on why the X
| background daemons are always 'incompatible' and gradle
| launches up new ones?
| gddhn wrote:
| Being new to Gradle, I used to run into this same issue. In
| one of the projects I use, I happened to find this comment,
| in github, which helped me fix the issue https://github.com/q
| uarkusio/quarkus/issues/10454#issuecomme...
|
| So increasing the default max heap size of the gradle build
| helped fix the issue
| https://github.com/quarkusio/quarkus/pull/10508/files.
| benibela wrote:
| And how could I make sure that the gradle I start on the
| command line and the gradle started by Android Studio use
| the same daemon?
| rwbhn wrote:
| Came here to post the same quote. Matches my experience as
| well.
| smitty1e wrote:
| Then there is Jenkins. I looked at the jenkinsfile and said
| "I guess Java and Python had a tryst?"
|
| Eventually we'll get to the GitLab CI/CD, but the existing
| disaster supports the status quo, so it's not a priority.
| noisy_boy wrote:
| My experience with JenkinsFile has improved once we setup
| library functions for it to leverage on. Only downside is
| that you need to write them in Groovy but the payoff is
| that the JenkinsFile reduces to basically a function call
| or two per stage which makes it super clean + it makes
| JenkinsFiles more or less "standard" (because there is
| practically no project-specific stuff in it - the
| complexity is managed by the library functions). This
| approach has made fixing issues or enhancements so much
| more easier for us.
| smitty1e wrote:
| The "goodness" of Jenkins for my use-case is that the
| service can be a kind of "sudo" for capabilities we don't
| want to spread around.
|
| That said, learning Yet Another Language that only deals
| with a niche requirement is a total bore.
|
| If we can cook it down to executing some garden-variety
| bash in a special context, along with some spiffy
| pipeline visualization, that is enough.
| noisy_boy wrote:
| At the end of the day, its just the shell executing the
| commands :) sure, you can always distil it down to a
| script (or a set of scripts) and nothing wrong with it
| either - as always, depends on the context.
| larusso wrote:
| I work a lot with gradle and had the same problems in the
| beginning. I overcome most problems by extending gradle through
| custom plugins and reading a lot of code. The documentation
| became clearer and clearer. Granted that is obviously not the
| desired way of learning a tool. Whenever I talk about Gradle and
| what it's biggest problems are it's exactly that. The
| introduction docs glance over so many aspects. It gets worse if
| you are completely new to groovy, Java and gradle. The idea to
| hide everything behind conventions is smart to keep the amount of
| configuration low. But if one has no idea about these conventions
| it becomes insanely hard to figure out how this black box works.
| One thing I have to disagree is the way he describes how to
| create tasks and that there are multiple ways of doing it. What
| he shows is the internal gradle API mainly targeted for plugin
| authors or gradle itself. There is no barrier. Build script
| authors should stay away from these APIs to stay forwards
| compatible with future versions. That's also why gradle has 3
| types of documentation: DSL, API and the raw Java Docs. Again
| nothing that makes the Tool easier to use for beginners.
| moonbug wrote:
| Gradle's purpose is to make cmake seem palatable.
| deathcap wrote:
| I forked a project [1] in 2015 to remove Gradle, and it then
| quickly subsumed the original project, remaining under active
| development to this day.
|
| There were other reasons, but de-gradling was one of the main
| motivations for my fork, and among the first of the major changes
| I made. The project is an implementation of an API which was
| discontinued by the original developers, but initially was built
| using Maven.
|
| After switching from Gradle (which the project switched to in
| 2014) back to Maven, build times significantly decreased and
| development became much more pleasant. I found Gradle to be like
| a speed bump slowing down development, and reverting back to
| Maven was like a breath of fresh air. Simple, straightforward,
| and fast. Maven may not be perfect, but it does the job well.
|
| [1] An open source Bukkit server implementation,
| https://github.com/GlowstoneMC/Glowstone ->
| http://github.com/GlowstonePlusPlus/GlowstonePlusPlus
| fctorial wrote:
| build.sh ftw.
| wbkang wrote:
| Recently I had the pleasure of learning Ruby and then suddenly
| Gradle started making sense. Things like having more than 1 way
| to do something, or the magic DSL syntax achieved by using the
| Ruby unary block syntax - it's a bit more understandable once you
| learn Ruby.
| ohgodplsno wrote:
| Ohohohoh Gradle. Making Android software turns this into a form
| of Stockholm syndrome, where you just get used to it. (And as
| some colleagues go, even pretend to like it. That is, until the
| next time it does something utterly stupid.) I have spent half a
| day trying to get a set of tasks to run depending on files that
| were changed since the original commit that started the git
| branch. This ought to be simple. Get all the files changed since
| the start, figure out their modules, figure out modules that have
| a dependency on those, run the tests only on those modules!
|
| In Gradle-insanity land, you'll need a whole plugin for that.
| That you have to register in the buildScript.classpath closure.
| Wait, is it also in the plugins block of the root file ? But
| maybe also the modules themselves, as an apply. Or is it a plugin
| block too ? Oh wait, you're using buildSrc ? Well that's a whole
| other problem. Don't forget you need a basic .properties file in
| META-INF that just gives out the plugin's name so it can discover
| it through reflection instead of having a proper API to do so.
|
| You would think the Kotlin scripts instead would fix it, but oh
| no. Not content with adding a solid 10 seconds every time gradle
| builds your model (which it rebuilds... Kind of when it feels
| like it), half of the pretended benefits of it simply do not
| exist. Almost all the documentation online is for the Groovy
| scripts, which is, obviously, incompatible with the .kts scripts.
| And I'm not just talking about syntax, no! Entire APIs are
| different. Setting a flag like `enabled = true` in groovy ? Have
| fun, we've added an isEnabled instead, because why not.
| Registering tasks? Wait, hold on, we've added new solutions in
| Kotlin! The existing APIs weren't batshit insane already, so
| let's abuse kotlin delegation. Kotlin's `by lazy {}` is nice and
| simple, why do we not make your write `val taskName by creating {
| }` ? And through some horrible logic, the name of your variable
| is what is exposed to Gradle. Or abusing the same thing for you
| to read things from a .properties file, because what is more
| clear than `val isFlagEnabled by project` ? Isn't it obvious that
| it's going to read a .properties file ? Not the values given
| through the -P flag when building though, because that would
| actually make sense. But wait! Let the gradle website explain to
| you the logic of lazy registered tasks. Why do you need these,
| you ask? Because Gradle is so absolutely terrible that having a
| large amount of tasks means they all get created when your daemon
| starts. Or when it performs anything.
|
| Oh, right, you need a daemon because why would you not need to
| eat 1GB of RAM just to not have horrible startup times for a
| build tool? Load all the tasks, at all the times! Add a
| development flavor to all your modules ? lol you've just doubled
| your amount of tasks.
|
| Let's add to this of course the absolute insanity that are the
| Android build tools. Making those work in a Makefile would be
| hell. aapt2, dexing... An absolute abomination of an amalgamation
| of bad tools (lol aapt2 silently ignoring your vector drawable
| overrides because it doesn't like the android:fillType
| attribute.) and horrible performance (aapt2 taking over a minute
| to process files on a medium sized project, or kapt (but that's a
| Kotlin problem) being awful in terms of performance.) All this to
| output a glorified .zip in the end. Or whatever new format's
| Google drug addled minds have invented to lock you in further to
| the Play Store and to make you give them your signing keys.
|
| I am not a fan of Gradle. Or Android's build tools.
| pjmlp wrote:
| Android is very special indeed.
|
| Not only has the Android team managed to push Gradle no matter
| what, they sell Android Java as the real Java.
|
| They purposely use Android Java samples, with its half broken
| support for modern Java, as means to sell Kotlin in the
| platform, and when one points out the real differences, radio
| silence.
| franzwong wrote:
| About point 6, even you don't execute task "a", gradle will still
| execute the configuration part of it.
___________________________________________________________________
(page generated 2021-01-16 23:01 UTC)