search

replay-framework / replay

Fork of the Play1 Framework
Other
19 stars 11 forks source link

Use Kotlin syntax for Gradle files #448

Open cies opened 2 weeks ago

cies commented 2 weeks ago

This is a ChatGPT experiment. The KTS syntax is popular for a while (so GPT is expected to be trained on it), conversions are common. Good candidate for a ChatGPT assignment.

It's easier for us as we use it internally. It's better tooled (type safety and with IntelliJ you have much more hints). And the preferred syntax for Gradle for a while now.

cies commented 2 weeks ago

I gave up. ChatGPT yielded shit: shit that looks super useful at first sight but turns out to be total shit. And the tricks that are needed to share versions strings will make it impossible for the dependency scanner to know the versions of the libraries.

Just learned about dependencyResolutionManagement which I need to start using in our project first...

cies commented 2 weeks ago

I've managed to upgrade our own Gradle setup to use TOML dependency catalogs: it allows us (1) to do away with a lot of workarounds (some of which RePlay also has), (2) has support for version re-use (version variables, to DRY-up version specs) and (3) at the same time makes the dependencies scannable by both IntelliJ and Dependabot.

If I find the time I will also implement this for the RePlay project, if no-one objects obviously.

xabolcs commented 2 weeks ago

Because of usage of Jenkins I know Groovy good enough to do magic in Gradle. Sadly I can't say that for Kotlin. :confused:

TOML dependency catalogs looks interesting but it shouldn't be part of the Groovy DSL -> Kotlin DSL change, IMHO.

cies commented 2 weeks ago

@xabolcs Are you against Groovy->KTS? With KTS Gradle got a lot better, IMHO -- type safety, editor hints, code completion, less use of strings.

I rather do all in one go as I have to fiddle around the Gradle files anyway.

I have the Groovy->KTS migration kind of ready on a local branch. But it would prevent dependabot to do it's magic. That's why I want to add the TOML catalogs, to fix that issue.

When I first ran into this my Gradle skills were to rusty, so I first implemented TOML catalogs for our project. Not that that's done I feel confident to take on RePlay, but not without your permission obviously.

xabolcs commented 2 weeks ago

Are you against Groovy->KTS?

If it helps you to manage Gradle files then it's OK to me, as you are a more active maintainer than me.

I rather do all in one go as I have to fiddle around the Gradle files anyway.

Well. I'll be sad (but won't veto it) if all the things end up in one big commit, as it would be hard to understand the diff later.

If it helps you, then migrate the project to Kotlin DSL in first step and do this TOML dependency in a later step.

For me the best would be to open a separate issue about using TOML depencency catalogs as it's not related the DSL itself.

cies commented 2 weeks ago

If it helps you, then migrate the project to Kotlin DSL in first step and do this TOML dependency in a later step.

The other way around makes more sense. As I need the TOML/catalogs to make the KTS easier write (we managed to remove many workarounds as the TOML/catalog thing really makes sense).,

I really understand the advantages of atomic commits. But there is not too many people working on this code, only a few projects that actually depend on it. For me the hassle in this case does not really live up to the benefits (unlike when working with a really large team on a code base that changes a lot and maybe even has several versions that need to be maintained: in a case like that I'd also be much more strict on the atomic committing).

xabolcs commented 2 weeks ago

The other way around makes more sense.

Then create an issue for it, with full of wishes what would you achieve, (Kotlin) examples and maybe I could lend a hand to implement! :slightly_smiling_face: