[HN Gopher] Gradle 7.0 Released
___________________________________________________________________
Gradle 7.0 Released
Author : gher-shyu3i
Score : 81 points
Date : 2021-04-11 16:06 UTC (6 hours ago)
(HTM) web link (docs.gradle.org)
(TXT) w3m dump (docs.gradle.org)
| la_fayette wrote:
| Gradle is a new problem to solve an existing problem and thus
| making it an even bigger problem. We tried to use gradle for an
| existing large spring application, after days of groovy and
| illogic we went back to maven... At least Android studio takes
| care of most of the gradle stuff. I will take a look at the
| Kotlin DSL, maybe it was just groovy.
| elric wrote:
| I quite like gradle for small projects. But as soon as the
| project reaches an arbitrary threshold of complexity, gradle goes
| from boon to bust. The venerable _ant_ is so much simpler to use
| in complex environments. Or maven, which -- unlike gradle -- has
| a pretty stable plugin API...
| jpgvm wrote:
| Lots of Gradle hate in here.
|
| To provide a counter-point I love Gradle.
|
| Yes it's complex, yes the learning curve is basically a cliff
| (you either understand Gradle or you don't) and yes it can be
| slow.
|
| But on the positive side:
|
| I use the Kotlin DSL and the majority of my new projects are
| Kotlin also. As a result I now have a single language in use and
| no need to switch contexts. Type safe, null safe DSL for build
| configuration that also happens to be the same language I want to
| write my project in anyway? Yes please. It's basically Ruby Rake
| but better in this regard.
|
| Potentially contentious point but I love being able to extend
| Gradle on a per-project basis with buildSrc plugins. This allows
| me to handle more complex tasks in a way that abstracts that
| complexity from the members of my team that don't necessarily
| have the same level of time invested in Gradle.
|
| I like that it downloads itself via wrapper script. My projects
| only have one local dependency, a recent JDK. The build system
| downloads itself, then downloads all the project dependencies.
| This makes it easy for non-JVM members of my company to check the
| project out, make a small change and build the project without
| learning 5 other tools. _cough_ Javascript _cough_.
|
| I like that it's versioned per project when using the wrapper. I
| don't need to worry about some sort of runtime or package manager
| switcher like you would in Python/Ruby/Javascript land.
|
| Don't get me wrong, Gradle is a long lived project with lots of
| skeletons in the closet but overall I think it's a very pragmatic
| tool for small projects all the way up to mid-sized monorepos.
| There does come a point when you will want to look at Buck or
| Bazel but most teams will never reach this point.
| tn1 wrote:
| > I like that it downloads itself via wrapper script.
|
| While I also use and enjoy Gradle, this is IMO its biggest
| weakness. We've all seen the recent supply-chain attacks, and
| ~everyone's infra is at risk here. There isn't even anything
| similar to Javascript's subresource integrity!
|
| I'm sure that the people hosting Gradle are very cautious, but
| it only takes one slip-up...
| jpgvm wrote:
| They could add a signature check to the wrapper script to
| resolve this concern.
| fcurts wrote:
| It already exists: https://docs.gradle.org/current/userguid
| e/gradle_wrapper.htm...
| CraigJPerry wrote:
| How are you finding build/packaging times with gradle + kts
| building a kotlin project?
|
| Gradle can be impressively fast (i'd hate to use a gradle build
| without the distributed build cache feature these days, what a
| difference), it can be reasonably easy to identify slow parts
| of a build (digging through build scans isn't too hard). When
| it comes to extending it, groovy is actually pretty comfortable
| for making little doo-dads to assemble some shell scripts from
| templates, or populate an h2 with some build metrics, or
| whatever you need, but all in all i think i'm over gradle.
|
| The speed is hard to keep on point, requires constant
| babysitting in a medium or large team and the learning curve
| really requires a reasonable working knowledge of groovy first
| (or kotlin - i haven't used the kts facilities) and a lot of
| java developers just aren't interested in learning properly so
| they hack something in which leads to band aids that get hairy
| easily.
| jpgvm wrote:
| Speed is fine, in the larger monorepo projects I have worked
| on implementing plugins using the worker architcture and
| paying attention to parallelism by splitting things into sub-
| projects appropriately always kept build time reasonable.
|
| You are correct that the biggest problem is that many people
| treat it as a distraction/unimportant part of their workflow
| and then wonder why things go badly.
|
| As the most senior member on most teams I am on I take it on
| myself to take charge of the builds, CI and other tooling to
| ensure this doesn't happen and all engineers are productive.
| Unfortunately that isn't a solution for everyone but IMO it's
| how it should be, you make yourself a 10x engineer by
| magnifying the performance of your other team members.
| einpoklum wrote:
| Suppose I'm a C++ developer on Unix-like systems. I know about
| Make and CMake, and maybe even a bit of meson and ninja. w.r.t.
| package management - maybe Conan; my OS distro; and getting stuff
| directly from the web.
|
| What are the pro's of me switching to Gradle? What would Gradle
| replace for me?
| kioleanu wrote:
| I have a project that runs specifically on Gradle 3.5. No more,
| no less. I am not making the mistake of touching that part of the
| project again.
|
| PS: thank you Gradle maintainers for offering a download of all
| versions at a click's distance
| tekkk wrote:
| Configuring Gradle is my vision of programming torture. It's a
| mandatory side step, unrelated to your main task. A mere chore,
| without any great programming paradigms to at least teach you
| something interesting. Just pure violence of leaky abstractions
| that can only be solved by sheer trial and error.
| zmmmmm wrote:
| I feel you. I think the only way out is to put aside time to
| actually start from scratch and actually learn it properly. A
| really big issue with Gradle is the pretense you can work with
| it easily without learning it. You absolutely have to
| understand its fundamentals (which are not obvious, btw) to
| work with it and not hate it I think.
| justin_oaks wrote:
| My experience with gradle (5+ years ago) was that there was too
| much "magic" going on. It would do things without me specifying
| that it should, like convention-over-configuration taken to its
| limits.
|
| Has that changed over the years? Has it gotten better or worse?
| jpgvm wrote:
| Better in some regards, worse in others. The Kotlin DSL I think
| made things a lot less magic at the cost of being a bit more
| leaky with abstractions.
| adonese wrote:
| I'm neither a java dev nor Android dev, but our android guy left
| the team and I had to maintain our android app.
|
| Gradle is really a huge burden for me to get the app up and
| running and for someone who was only lightly interested into
| doing small changes one the fly, gradle was totally upsetting.
|
| I think it kinda fits into tools that suit much large scale
| projects, while they fall short to address small scale projects.
| dvfjsdhgfv wrote:
| Sometimes I feel they should stop the development of all new
| features and concentrate exclusively on performance improvement
| (which, fortunately, is not neglected in this release).
| popotamonga wrote:
| I never understood why my android app with only 300 classes and
| 20 libs takes more than 1m to build on my custom 5k$ computer.
| In comparison i have a c# project 3x bigger and only takes a
| few seconds to fully rebuild.
|
| Maybe its just how android is and nothing to do with graddle
| but still...
| ohgodplsno wrote:
| A lot of it is Android, yes. A regular build run will involve
| kotlin annotation processing, kotlin compilation, java
| annotation processing, java compilation, AAPT2, dexing,
| sometimes d8/r8 if you're in release mode, as well as a whole
| host of various processes that you can forget about until it
| hits you with a build error that will have you puzzled for a
| few hours.
|
| EDIT: right, Jetifier too, because that's always a lot of
| fun.
| okr wrote:
| Yup. I also stopped upgrading. Too much work.
| josteink wrote:
| Granted it was many years ago, but my only experience with
| Gradle was through Android Studio.
|
| Basically, as I remember it, every time Android studio
| updated Gradle, my project broke. _No exceptions_ , even
| though this was a stock Android Studio project.
|
| Seemingly things are still that terrible? If so, why do you
| people keep using it?
|
| What problems does Gradle solve which other build-systems
| don't solve better
| ohgodplsno wrote:
| Gradle is sufficiently implanted into the Android ecosytem
| that moving away is hard. When you have a project with 80+
| modules, buildSrc contents, gradle plugins, well, moving to
| Bazel isn't exactly a one day job. Add to that that many
| things add Gradle plugins that might be necessary for your
| workflow, and well, you're in a bad state.
| thu2111 wrote:
| Unfortunately that's also now the case for the Kotlin
| ecosystem. I attempted to use Maven recently for a simple
| Kotlin project and recently switched to Gradle. This is
| NOT because I like Gradle. Oh god if there is any project
| and company that badly needs some competition it is
| Gradle Inc. But the Maven/Kotlin ecosystem is bit-
| rotting. Maven itself is hardly maintained. It's now
| common to find libraries or tools that only really work
| properly with Gradle and de-prioritise Maven related
| issues. Gradle is winning by default, even though it's
| arguably a step sideways from Maven.
| vbezhenar wrote:
| What features do you think they should not ship? Apple Silicon
| support obviously is necessary. Support for Java 16 is
| necessary. Centralized dependency management is long-awaited
| feature. Type safe project accessors are very nice to have.
|
| I would say that they should not stop the development of all
| new features, but rather they should spend more time designing
| those features, so they don't have to change them in the future
| (making old variants obsolete and broken in the end). But
| modern software development is agile, move fast and break
| things and all that.
| avmich wrote:
| Even before that I'd prefer them improving the documentation :)
| . It's pretty senseless to have a system with even a good
| performance which can't be used because of a cryptic behavior.
|
| I'm yet to see a good explanation for how Gradle should be
| used. Is knowing Groovy a prerequisite?
| scaladev wrote:
| These days you can write build scripts in Kotlin. It provides
| proper type checking and better auto-completion.
| vbezhenar wrote:
| I don't know which documentation do you miss. Gradle has
| pretty extensive documentation, stackoverflow has all kinds
| of answers and other websites have plenty of tutorials.
|
| I don't know Groovy and I was able to write complicated
| enough multi-project builds with some custom build steps by
| copy-pasting snippets from the Internet and applying some
| common sense. I guess, Groovy knowledge is required if you
| need to write build plugins.
| vesinisa wrote:
| No, Gradle's documentation is really terrible. There is
| just no easy path to _learn_ it - you will with time and
| pain learn a bit of the interface, but deep down it remains
| mostly unfanthonable, unnecessarily complex and filled with
| strange quirks. Bruce Eckel had pretty much the same
| experience as myself:
| https://www.bruceeckel.com/2021/01/02/the-problem-with-
| gradl...
|
| Everone "learns" Gradle by copy-pasting snippets from the
| Internet and then having to fix them when they break. And
| what little I have learned of Gradle over the years was
| certainly not thanks to their documentation, but other
| people explaining the concepts in blog posts and tutorials.
| The Gradle documentation always assumes that you will want
| to learn the whole build system from ground up. There is no
| simple documentation for people who see Gradle just as a
| tool secondary to their actual product that is just built
| with it.
|
| It is in many ways similar to git. You can't really learn
| git unless you learn it from the ground up. But git is
| actually really simple when compared to Gradle, and most
| people do learn git eventually through using it. But I am
| yet to encounter a developer who actually learned Gradle
| inside out just from using it and reading the
| documentation.
|
| Oh, and at least git's interface and structure has remained
| mostly static ever since the original concept by Linus in
| 2005. Same can not be said of Gradle - I feel like the
| developer interface is like a sand castle that is washed
| away every second release, and I assume the internals keep
| shifting as well. What a nightmare to work with.
| njitbew wrote:
| This is funny, because I have the complete opposite
| experience. Yes, it took me an afternoon to find my way
| around Gradle. But ever since I really appreciate their
| documentation. It is to the point, well written, contains
| code samples (which I believe are unit-tested, so they
| the code samples are always up-to-date), contains
| examples in both Groovy & Kotlin, and I could keep going
| on. A good entry point, for example, is Build Script
| Basics (https://docs.gradle.org/current/userguide/tutoria
| l_using_tas...).
|
| > But I am yet to encounter a developer who actually
| learned Gradle inside out just from using it and reading
| the documentation.
|
| You just met him! ;)
| vesinisa wrote:
| You are probably doing a bit simpler stuff, if that basic
| tutorial suffices you. I should have maybe added that I
| do Android development with Gradle. There you don't as
| much start with an empty build file to write the tasks to
| compile your project, but instead have to navigate a pre-
| existing large build file and figure how to correctly use
| the Google and Gradle interfaces to integrate to the
| Android build tools, such as the dreaded AGP (Android
| Gradle Plugin). Which by the way is actually mostly
| undocumnented AFAIK!
| avmich wrote:
| The problem is not all developers have such a nice
| experience. Maybe the reason is underlying assumptions -
| they can really help in learning or become a really big
| obstacle, if one isn't aware of them. That or another, my
| several attempts to grok Gradle from existing scripts and
| documentation still fail to produce understanding.
| Hackbraten wrote:
| One thing that keeps disappointing me is the utter lack
| of reference-style (API) documentation. Sure, the
| conceptual documents contain examples. But if the example
| isn't clear enough, you're completely on your own.
|
| For example, the following document has been largely
| useless to me even though I've spent whole days trying to
| make the examples work for me: https://docs.gradle.org/cu
| rrent/userguide/cross_project_publ...
| jlund-molfese wrote:
| These days the Kotlin DSL is treated as a first class citizen
| and you can find examples for most common tasks in either
| language. But Groovy is pretty easy to pick up too, you
| definitely don't need to know it before you start using it
| with Gradle.
|
| Aside from the performance implications, Gradle excels when
| used with more complex builds with many steps. If Maven works
| for your use case, your build scripts aren't unmanageably
| long, and your team doesn't mind XML, there isn't much of a
| reason to switch.
| ohgodplsno wrote:
| Sweet can't wait to repeat the gradle update cycle!
|
| * "Gradle update? Performance babyyyy"
|
| * "Oh, <obscure feature that needed to be hacked around> no
| longer works. It's okay, let's fix it.
|
| * "Oh, no, it's actually not backwards compatible and I have to
| figure out what kind of awkward cast as an
| <AndroidPluginInterface> I have to do because gradle still
| doesn't expose proper types in half their kotlin DSL"
|
| * "Right, entire build cache gone. It's okay, 15 minutes."
|
| * "right! Now let's get an incremental change and see the
| perfo... Right, kapt still isn't incremental"
| The_rationalist wrote:
| _Right, kapt still isn 't incremental"_ Why isn't your KAPT
| incremental? _Kapt supports incremental annotation processing
| that is enabled by default. Currently, annotation processing
| can be incremental only if all annotation processors being used
| are incremental._
| ohgodplsno wrote:
| androidx.room is only incremental starting from 2.3.0-beta3.
| No stable release yet.
| miked85 wrote:
| I never understood why one would want to use Gradle over Maven.
| Gradle seems like a very complicated way to avoid using XML as
| configuration and essentially end up with Ant.
| ptx wrote:
| One big advantage is the Gradle daemon, which (in return for
| consuming all available memory) saves you from having to spin
| up the JVM every time you build and can be substantially
| faster.
|
| It seems someone has recently created something similar for
| Maven: https://github.com/mvndaemon/mvnd
| felipelemos wrote:
| I wish maven would work with something other than XML.
| mdaniel wrote:
| It seems merely adding a file to the .mvn directory will do as
| you wish: https://github.com/takari/polyglot-maven#usage
|
| I have avoided that road because it's one more thing that is a
| snowflake in the very area where I don't want to blazing
| trails. But I have personally tried their approach before and
| can confirm it does work as advertised. I can't recall if IJ
| lost its mind over pulling a stunt like that, but arguably if
| it did, then filing a YouTrack is an appropriate next step
| carrja99 wrote:
| When I was last doing Java development ten years ago they had a
| groovy dsl, did they discontinue that?
| krzyk wrote:
| DSL is what is wrong with Gradle.
| kohlerm wrote:
| I wish maven would have a proper way to resolve version
| conflicts and incremental builds
| tarkin2 wrote:
| First there was Ant. Ant was bad. Then there was Maven. Maven bad
| less bad. But still bad. Then there was Gradle. Gradle was even
| less bad. But still bad. Show me the build tool - I'll show you
| the bad.
|
| My main gripe is that it changed so quickly. All my notes quickly
| became useless. And it was slow. Gradle daemon promised to help.
| And it did help. (And became even more of a resource hog) But it
| was still bad. Show me the build tool - I'll show you the bad.
| miked85 wrote:
| Ant wasn't bad, it was a big step up from using Make for Java
| builds.
|
| Maven wasn't bad either. It tried to enforce convention over
| configuration, while also introducing a native dependency
| management mechanism.
|
| Gradle was/is bad and serves no real purpose.
| sheikheddy wrote:
| Does anyone have a good resource for learning a systematic way to
| do dependency management for large codebases? Seems like every
| time it comes up in gradle or maven I have to trial-and-error my
| way out of resolution hell.
| bitcharmer wrote:
| Just use Maven. Could you point out what exactly in Maven makes
| it hard to use for you?
| jpgvm wrote:
| Maven makes doing things off the beaten path very hard. This
| can be good as most Maven builds won't surprise anyone but if
| you often find yourself doing such things (mixed language
| projects, custom code generation steps, etc) then Maven will
| always be harder to use and you will have to spend more time
| writing plugins vs Gradle.
|
| Maven is great when all you want to do is build a simple Java
| project and publish it, when you step outside of that it
| becomes much more painful.
| andrewaylett wrote:
| Maven is great so long as there's a plugin to do what you
| need to do. If there isn't, it's quite possible that
| writing one will be simpler than trying to coax Maven into
| doing something unorthodox.
|
| For example, here's an old plugin I put together to allow
| easy publishing of a third-party artefact to a repository
| that didn't have a web interface for such things:
| https://github.com/andrewaylett/prepackaged
|
| It's old enough that the infrastructure I set up around it
| has bit-rotted -- I've just pushed a clone to GitHub to
| share here :). I'd hope using modern language features
| would make it easier still.
| bruce343434 wrote:
| Cool ad
| avolcano wrote:
| Interesting discussion here. I've been very happy with Gradle for
| my first major JVM project, a small Kotlin API with a simple
| build configuration (https://github.com/thomasboyt/jam-
| buds/blob/master/rhiannon/...). I suppose I'm not surprised to
| see more complaints from folks who have worked with it on much
| longer-lived and _much_ more complex projects.
|
| I've been thinking of taking a peek into Java, which I've never
| really written[1]. Is the general thinking that, for something
| like a Spring Boot application, it's much better to just start
| with Maven? I'll admit I am, aesthetically, displeased with the
| mountains of XML config I've seen in some tutorial articles, but
| I imagine it's a lot simpler to maintain over time than any DSL
| would be.
|
| [1] slightly off-topic, but if anyone's curious why: I haven't
| been very impressed by any of the "Kotlin-first" JVM libraries
| I've seen (like ktor or exposed), I think coroutines are neat but
| much more suitable for main-thread-focused situations like
| Android apps than something more easily threaded like web servers
| (and with Project Loom hopefully upcoming in the next couple
| years this might be a moot point soon), and I don't like the
| JetBrains tooling lock-in (e.g there's no well-supported language
| server for Kotlin, unlike what Red Hat's been building for Java)
| crossroadsguy wrote:
| Gradle had a lot to do with my attempts to move away from Android
| development. Well, not that other tools are shiny beacons of
| goodness, but still Gradle takes the cake effortlessly.
| agilob wrote:
| I feel you. Gradle is the reason why I stopped updating my
| opensource android projects and killed them. I once got updates
| to translation files, wanted to update gradlew as it was ~2
| years old. Failed with updates for +16 hours spent on it.
| Multiple gradle functions replaced or removed, dozen of
| incompatible changes, broken syntax, incompatible gradle
| plugins I used for C compilation... I simply gave up, archived
| the repo, stopped accepting translations and moved away from
| Android. Simply too much effort was wasted trying to keep
| dependencies up to date every year or so.
|
| Just look at some of these breaking changes reported for 7.0:
| [#16652] - Trouble using centralized dependency versions in
| buildSrc plugins and buildscript classpath [#16620] -
| FileNotFoundException in TestKit tests: lib-
| android/build/20210320_1519030999411730848.compiler.options
| [#16541] - Impossible to run modular program with
| 7.0-milestone-2. Working with 6.8 [#16532] - Build
| failure when including a plugin build in settings & applying a
| settings plugin [#16163] - Using included builds for
| local settings plugins don't seem to work [#16028] -
| Change in behaviour when resolving custom project dependencies
|
| I without going into details, two of these would affect the
| project I talked above... These breaking changes should be
| enough to block release of 7.0 before 100s of developers are
| hit by these time-wasting issues.
| charrondev wrote:
| Also seems like a horrible idea to use a custom DSL for the
| configuration. Just another curveball to throw at you.
|
| XML, yaml, toml, json, something else standard and well known
| would have been nice.
| zmmmmm wrote:
| It's only really "custom" if you don't know Groovy. Plenty
| of build systems invent a whole custom language for it so
| it is one step better than those - at least by the time you
| do learn groovy you have picked up a transferrable skill.
|
| I do think that one of the big problems with Gradle is they
| try to operate under a pretense that you don't need to
| learn any Groovy to use it. The reality is you can get just
| far enough to get yourself in trouble and then suddenly you
| are mired in inexplicable problems, and just start hating
| the tool.
| jorams wrote:
| I don't think this criticism makes much sense. XML, yaml,
| toml or json would replace the current choice of Groovy or
| Kotlin, but the actual configuration would be just as much
| of a DSL.
| this_user wrote:
| Gradle has unfortunately gone the way of Maven in terms of
| becoming more and more of an unnecessarily complicated time
| sink.
| jhhh wrote:
| To support java 16 all I had to do was change the release tag
| in my compiler plugin and everything just worked. Didn't have
| to ugprade maven, didn't have to upgrade the compiler plugin.
| Gradle users had to wait until they released another entire
| major version with all the churn that entails.
| levosmetalo wrote:
| Sorry, but maven is an order of magnitude better than gradle.
| In most cases it just works and is blazing fast compared with
| the alternatives.
| bitcharmer wrote:
| I have the exact opposite experience. Been on tens if not
| 100+ Java projects over the last 20 years and 99% of
| developers I worked with moved away from Gradle after
| migrating to it from Maven. It's just harder to work with.
| Maven is super low-maintenance in comparison (and just
| works).
| isbvhodnvemrwvn wrote:
| And Maven makes writing custom build logic _just hard
| enough_ to discourage people from doing so, which is a very
| good thing, from my experience of having worked with Gradle
| for 5 years or so.
| njitbew wrote:
| The problem is that it is super easy to modify a Gradle build
| scripts, but also super hard to get it right (e.g.
| understanding of configuration vs. execution phase, concept of
| configurations, task dependencies). As long as you don't touch
| the build script, Gradle is superior to Maven in _so_ many
| ways.
| jpgvm wrote:
| Yes, it has what I would describe as a cliff learning curve
| and I think that is it's biggest drawback. One understands
| Gradle or one doesn't and that is pretty far from ideal.
| [deleted]
| Traubenfuchs wrote:
| Gradle considered harmful.
|
| https://phauer.com/2018/moving-back-from-gradle-to-maven/#tl...
| bitcharmer wrote:
| The move from Gradle back to Maven I've seen on all Java
| projects employing Gradle so far (and I worked on many such
| projects).
| edoceo wrote:
| On one hand we've all these devs who love the new tooling. And I
| feel like some geezer when I complain about vendor-driven churn.
| And here's a great example, and many complaints and stories. And
| I'm sad the lesson wont be learnt this time either
| kohlerm wrote:
| Version catalogs Sound Like an interesting feature to ne.
| bambam24 wrote:
| This project is still alive? Why??
| ur-whale wrote:
| Grade is a shiny beacon exemplifying the mindset of the entire
| Java ecosystem.
___________________________________________________________________
(page generated 2021-04-11 23:01 UTC)