Hey all, For the longest time I've been using `rem...

# dokka

[simon.vergauwen]

Hey all,
For the longest time I've been using removeChildTasks, and it's been deprecated for a long time 😅 (I am finally cleaning up our Gradle config in Arrow...) What is the recommended way to fix this?

dokkaHtmlMultiModule { removeChildTasks(undocumentedProjects) }

[Adam S]

unofficial answer: use Dokkatoo :) https://github.com/adamko-dev/dokkatoo

[simon.vergauwen]

Looks really great, but we're having a hard time investing time atm as well 😕

[simon.vergauwen]

I assume I cannot use it as a drop-in replacement?

[Adam S]

It depends - how much custom config do you have? If it's just the basics, then it should be easy. And is it just outputting html?

[Adam S]

There are some comparative Dokka/Dokkatoo examples in the repo

[simon.vergauwen]

It's just outputting HTML, and config is not complex. Only linking Std, KotlinX Coroutines and Serialization (in some modules). We've had soo many issues over the last 8 years we kept removing and removing stuff, and ended up in the most default config I think.

Everything below this point (more-or-less), https://github.com/arrow-kt/arrow/blob/2860c124f9628af4cdf1cb2bddae2f7484697cf4/build.gradle.kts#L102

[Adam S]

thanks for sharing! It should be pretty simple to set up, but (going a little off topic) the project doesn't have any buildSrc or convention plugins... Is that something you've looked at?

[simon.vergauwen]

No of the maintainers have strong Gradle skills, I've been trying to get someone to contribute to our horrible Gradle setup but so far unsuccessful. I actually want to solve that, but I don't know anymore what is best practice..

We've been publishing Gradle plugins to share between projects, but tbh that has also been quite cumbersome. I am currently removing the publishing stuff in favor of Gradle Maven Publish Plugin, and I want to get of that entire repository tbh. Only relevant thing there is setting up Kotlin (w/ Kover, Knit & Dokka).

99% of the project has the same Kotlin configuration, except 3 JVM only modules.

[simon.vergauwen]

I used buildSrc long ago, and still do on some projects, and have also used conventions plugin I think (includeBuild with a nested Gradle plugin project).

[CLOVIS]

@simon.vergauwen I could contribute to clean up Gradle stuff if you're interested. We'd need to discuss exactly what you want though.

I currently manage half a dozen repositories with shared config between them. I migrated everything from Dokka to Dokkatoo about a year ago (mainly for the performance & reliability improvements), so I could help with that too

[simon.vergauwen]

That'd be really awesome @CLOVIS 🙏 I discussed it with @Alejandro Serrano.Mena but we don't have a strong idea. If you have experience with this then maybe you know better than us 😂

We have https://github.com/arrow-kt/arrow-gradle-config which has modules for everything, but as I see it:
• publishing/nexus is being deprecated and replaced by Gradle Maven Publish Plugin
• Versioning (still unanswered)
That leaves configuring Kotlin (targets, and formatter), which I think is probably better in buildSrc, or convention-plugin (?). I basically want the configuration that 99,99% of Kotlin devs are familiar with. I think this is a case of simple/duplication > re-using. Since the effort of re-using is too high that it doesn't seem there is a return of investment, at least to me.

WDYT? Shall we move this conversation over to #arrow-contributors?

[CLOVIS]

If you have experience with this

I have some experience, but I'm fairly confident it should be enough for Arrow.
• I did the cleanup for Datamaintain. TL;DR : all common build logic goes into convention/precompiled plugins in the same repository. Intuitively I think this what the Arrow team would be interested in
• I also maintain this monstrosity, which is similar to arrow-gradle-config but two steps further (there's a "plugin" plugin that configures all plugins. But it is, after all, a plugin, so it configures itself using its own code). I don't necessarily believe going this far would be appropriate 😅

Shall we move this conversation over to #arrow-contributors?

I think it would be better, yes 🙂

[Adam S]

> That leaves configuring Kotlin (targets, and formatter), which I think is probably better in buildSrc, or convention-plugin (?)
Yes, I agree with moving Kotlin target config into the repos. Explicit and localised config, and some duplication, is a lot easier to understand with than strict global config. (Tangent: It was such a hassle working with Maven when a parent-pom was overly opinionated. It's nice that Gradle is flexible!)

[Adam S]

If Arrow has some specific publishing configuration that might be nice to share. For example, some defaults for the POMs, or artifact credentials. But that's possible to set up in a Gradle friendly way (convention plugins that just provide defaults if the Maven Plugin is applied).

[Adam S]

if you need any help, let me know, but you're an expert @CLOVIS so you'll figure it out :)

[CLOVIS]

an expert? 😅 I barely understand what I do 😂

[Adam S]

if you maintain a separate repo for Gradle conventions then you're an expert haha, I don't even have that!

[CLOVIS]

I have so many projects I need to keep sync'd 😢

[simon.vergauwen]

If Arrow has some specific publishing configuration that might be nice to share. For example, some defaults for the POMs, or artifact credentials.

We have nothing crazy, vanilla Gradle Maven Publish Plugin does all we need.