Discussion around the Gradle setup about arrow

[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 🙌

[CLOVIS-AI]

From what I gather, the final objective is to have as much as possible in this repository, and avoid using the Arrow Gradle Config repo altogether?

If so, what's your plan when you want to create spin-off repositories?

Sorry for the long time to answer, KotlinConf was wild!

[nomisRev]

Sorry for the long time to answer, KotlinConf was wild!

No worries, no time pressure for OSS but KotlinConf really was wild 😂

If so, what's your plan when you want to create spin-off repositories?

To be honest I was thinking we'd just have a little bit of duplication. The formatter is a non-issue, it's a 1 liner in 99% of the cases. So that only leaves configuring the targets, is it worth it keeping that in a separate repo? All spin-off repositories seem to have slightly different target requirements since they build on top of specific stuff.

• SuspendApp, posix APIs so this excludes mobile devices and non-NodeJS.
• Ktor, follows targets from Ktor, which are not the same as Kotlin Std, or KotlinX
• ?