Discussion around the Gradle setup

[CLOVIS-AI]

Hi! @nomisRev asked for help with the Gradle setup of Arrow, and I'm interested in helping. However, I'm not too familiar with the existing setup nor what you expect, so I'd like to discuss it a bit first.

My understanding is the main problems at the moment are centered around Maven Central and duplication in build.gradle.kts files? For Maven Central publication, I'm not an expert, but I have migrated all my projects to this plugin and haven't had any issues since. In particular, this plugin allows publishing an artifact in multiple steps (e.g. to build the JVM/JS platforms on one machine, the iOS platforms on another machine, and then combine everything into Nexus).

Now, for the config duplication;

---

The first and most important question is whether you want to share configuration between multiple Arrow repositories. I see there is https://github.com/arrow-kt/arrow-gradle-config, but I haven't looked much into it yet. Sharing config between repositories by publishing convention plugins is the most effective solution, but comes at the cost of quite a lot of flexibility (on each change, you have to edit the conventions, publish them, bump the version in the downstream repository).

If each repository is different enough, then they may each have their own convention plugins to share internally. However, this is a bit slower because Gradle isn't that performant on up-to-date checks. It also increases the time-to-index when opening the project for the first time, but I don't know how much you care about this.

Looking at the current state, I guess you're aiming for a hybrid approach; how do you decide what goes into arrow-gradle-config or not?

[nomisRev]

Hey @CLOVIS-AI,

The Arrow project is very old, and it has gone through a lot... Over the years we've moved more, and more to "vanilla" configuration, and were able to get rid of our custom tooling in favor of new 1st party tooling (like KotlinX Knit).

The Arrow Gradle Config came to live only because we were stuck with publishing KMP with 1.0. Since we didn't know what to do we turned to the community, and Arrow Gradle Config was born but was quickly abandoned. So personally I am in favor of getting rid of Arrow Gradle Config, because the maintenance costs are way too high, and it's constantly been behind since its inception.

Requirements:

• Publishing: fully replaced by Gradle Maven Publish Plugin.
• Dokka: moved into Arrow config during 1.x
• Kotlin Configuration: Targets & explicitApi (&?) Arrow Gradle Config Kotlin
• Formatter Arrow Gradle Config Formatter. Spotless is a single line configuration, so I would just inline the necessary code. (I think Arrow Gradle Config is over-configured here??).
• Versioning: This is currently disabled, due to versioning plugin not respecting previously released alpha, beta, and RC releases. Not blocking, we can figure out something down the road.

@CLOVIS-AI, to be completely honest I don't think a lot of us have a strong opinion about this. My goal is to move towards what is recommended, and/or most used, in Kotlin. This will improve ease of contributions, readability, and maintenance. So feel free to make a counter proposal, or suggest any other changes to our Gradle configuration.

Thank you @CLOVIS-AI 🙌