Is Amper meant to replace Gradle completely in the...

# amper

[henrik]

Is Amper meant to replace Gradle completely in the long term?

[eygraber]

https://kotlinlang.slack.com/archives/C062WG3A7T8/p1716390229721689?thread_ts=1716390229.721689&cid=C062WG3A7T8

[Sergey Aldoukhov]

I hope Amper kills Gradle eventually.

[eygraber]

Well it definitely won't kill it, because there's an enormous ecosystem outside of Kotlin. But I truly hope that Gradle sticks around forever with Kotlin. I'm more excited by the declarative Gradle work that Gradle itself is experimenting with, but I would be happy even without that.

[Sergey Aldoukhov]

Well, we are talking hopes here, right? I’m not saying Gradle gonna die, but I would be glad if it ever happen. Woking on multi - module projects is more painful with Gradle than with Amper.

[eygraber]

Must be an opinion thing. I find it much easier and much more powerful with Gradle 😅

[rocketraman]

I think you've got two audiences when it comes to build tools: you've got companies that have entire teams dedicated to DX and tooling (e.g. Netflix, Facebook, Google), and you've got small companies and individual developers, and developers inside those big firms that just want a simple and easy to understand declarative build to work without having to paste complicated code snippets into their build dammit!

Where I think both Amper and the "Declarative Gradle" projects are focused is on the latter, as pretty much everyone agrees that Gradle exposes too much of its complicated but powerful internals to end-developers.

Speaking with absolutely no inside knowledge, the teams that need the underlying power of Gradle aren't going away, so I doubt Amper will take over from Gradle in the medium to long term. I'm guessing that Amper will become a "quick and easy" solution suitable for tutorials, templates, and most projects in the wild, while Gradle will live on for people that need the additional capabilities it provides. And another prediction: Gradle will offer an "upgrade my build to Gradle" tool for Amper users.

[eygraber]

I could be an outlier, but I've never had that experience. Since I started working with gradle I've either been on my own, or had no more than 2 other teammates. I'm not a full time build engineer, or dedicated DX.

[eygraber]

I also maintain a bunch of other projects where I'm on my own. I just took the time to understand how it works, because if I didn't, no one else would.

[rocketraman]

I'm mostly in the same boat, and I've often cursed Gradle's complexity. Just look at this question on Stackoverflow as an example: https://stackoverflow.com/questions/18487406/how-do-i-tell-gradle-to-use-specific-jdk-version. Most of the answers there are wrong for modern Gradle, until you get to mine somewhere down the list.

[rocketraman]

Gradle does some very weird things like having a ~/.gradle/gradle.properties take priority over a per-project settings file (https://github.com/gradle/gradle/issues/12283)! And this has no easy workarounds (more code snippets from the Internet pasted into a build to workaround the tool!). I've had this almost cause more build issues for me than I can count on one hand.

[Stylianos Gakis]

I hate to be that guy, but if you've written a convention plugin you're already an outlier. Amper isn't targeted to you really. And I'm sure there are millions who use Gradle and haven't gone even that far. There's definitely room for both to exist.

[darkmoon_uk]

I've found considerable success in scaling my teams efforts across multiple projects, by growing standalone libraries out of emerging regions of domain/generalisation in our App projects.

Current examples from my FinTech domain: Growing KMP libraries for Financial Calculation and for robust Connectivity with failover/failback between the various connection methods on a mobile device.

These are subsystems that team members can better focus on, develop with greater speed and tighter feedback loops, when they're in separate repo's with their own Compose Multiplatform Dev Apps.

We rely heavily on advanced Gradle features and Composite Builds in particular to make this scaling work - and there's a well defined lifecycle: First the target project module becomes a fully fledged Gradle project in the consuming parent repository, it can be `includeBuild`ed in, meaning there's little change in the Dev experience at first.

Accompanying that new standalone Gradle project are two more Gradle projects: a KMP Dev App, and a workspace project which just uses Gradle Composite to bring the Library and Dev App together. This workspace project is literally just:

//settings.gradle.kts
includeBuild("../architecture")
includeBuild("../architecture-devapp")

...but this is where the productivity boost happens: Developers use the Dev App to bugfix/build on the subsystem, doing their 100 or more subsystem-focused iterations before doing the heavier integration into the wide~r~ app project, and all the weight of lengthy build that implies.

Over the space of months, as a subsystem's code changes slow down indicating maturity, we can switch to publishing/resolving by binary package, speeding up the main project build times, while moving out the library into its own repo.

This approach does result in a high number of projects, so all of them share an in-house Gradle plugin that keeps their configuration concise; offering functions to interact with the CI environment, support layout conventions, publishing and more.

There is probably nothing novel in the process I've described but it's a strategic progression for scaling-out a code-base that's well supported by Gradle and I can't see how it would work in Amper yet.