I've seen the <FAQ for why Gradle isn't being exte...

# amper

[eygraber]

I've seen the FAQ for why Gradle isn't being extended, but I'm still not getting it. Does Amper provide something that Gradle isn't able to?

At the surface it seems to be that Amper could be a regular gradle plugin with an easier to work with extension, like how convention plugins work.

I'd hate to see the build system get fractured (especially after investing a lot of time in mastering Gradle 😅).

[christophsturm]

Mastering gradle is exactly the problem imo. A build system should not be something you have to master.

[eygraber]

I don't think you need to master Gradle. I just happened to have done that (I hope) 😄

[czuckie]

I think one of the most frustrating things with kotlin multiplatform in the past (wow is it really?) 6 years, is that the gradle configuration has changed a lot and different mechanisms have been introduced and removed etc.

It feels like Amper provides a high enough abstraction from gradle that those changes can happen without having to modify the amper yaml which I think is good.

At least, I feel like if I put together a project using amper now, in 6 months time I'll be able to use the latest and greatest without anything (ok maybe a few things) breaking.

This was almost a guaranteed no go with the Gradle stuff, at least it had been for me!

[eygraber]

I've had convention plugins that I maintain for making it simple to use KMP and CMP in any kind of project. I don't see why Amper can't be like that. Apply the convention plugin, configure the ergonomic extension, and it ends up looking exactly the same as the Amper examples do

[joseph_ivie]

This is my problem with Gradle personally; everybody maintains a conventions plugin. Every time I go open someone else's Gradle project on GitHub I feel like I find a new one, if not one embedded in directly. If JetBrians makes conventions plugins unnecessary I'll party.