Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This PR partially addresses #3670: it contains working example, but doesn't contain any docs. This example contains compilation and test execution for all the modules of https://github.com/arrow-kt/arrow for the JVM and JS (Node) targets, except [arrow-optics-compose](https://github.com/arrow-kt/arrow/tree/main/arrow-libs/optics/arrow-optics-compose) module (it requires better Android support by Mill). Full example run takes 6 minutes on my machine, so it is extracted into a dedicated CI job. The following Gradle plugins are not added to the example build script, because their respective tooling is Gradle-dependent (no raw-jar or CLI): * https://github.com/xvik/gradle-animalsniffer-plugin (although maybe it is possible to use options from https://www.mojohaus.org/animal-sniffer/) * https://github.com/Kotlin/kotlinx-knit * https://github.com/Kotlin/binary-compatibility-validator * https://github.com/diffplug/spotless There is also no publication support in this example (requires Kotlin Multiplatform publishing support, see #3867) I faced the following issues while writing this example: * There is quite a lot of duplication for JVM/JS configuration, because there is no support of [Kotlin Multiplatform hierarchies](https://kotlinlang.org/docs/multiplatform-hierarchy.html) * Each Maven or Module dependency should be with JS/JVM/etc. target qualifier, which also quite explodes amount of code to be written. This is also a question of Kotlin Multiplatform hierarchies support and resolution. * Until KMP hierarchies and target resolution support is not implemented, adding a new compilation target will bring quite a lot of new code in the build script. And there is a lot of targets in Arrow: https://github.com/arrow-kt/arrow-gradle-config/blob/97ba7b5eab810a336cf4070eb717f05533d208a8/arrow-gradle-config-kotlin/src/main/kotlin/io.arrow-kt.arrow-gradle-config-kotlin.gradle.kts#L34-L69 * There is no possibility to disable tests for the particular module (so I had to use a hack with overriding `compile` / `test` tasks) - this is because tests is dedicated module, but if comes as a part of the trait, we cannot add / remove it dynamically. Having such control is handy when certain multiplatform modules have a common trait for the main compilation unit, but some of them may have no tests. Regarding docs: I think it is too early to write any comparison with Gradle, because clearly new functionality will be added to the Kotlin support in Mill which will affect overall execution time and also the comparison should be done not only for JVM targets, but for Kotlin/JS and Kotlin/Native targets as well. And ideally it should be a defined methodology for such testing (for example, certain Gradle plugins should be removed from the Arrow Gradle build script, to have the same set as Mill build script; compiler execution time should be excluded (it may be different because of the different flags passed to it under the hood)). So I propose to open a dedicated bounty for writing such doc. --------- Co-authored-by: 0xnm <0xnm@users.noreply.github.com> Co-authored-by: Li Haoyi <haoyi.sg@gmail.com>
- Loading branch information