We need a build system for Kotlin. We have reached...

# compose

[Abdhilahi Wabwire]

We need a build system for Kotlin. We have reached our limit with Gradle. We switched to Bazel but this is temporary. We are looking at going back to Maven. Gradle is now costing our company massive sums of money.

[Pablichjenkov]

You can ask here #gradle
If you decided to go with gradle enterprise, well, I believe your company had a reason for that.

[Abdhilahi Wabwire]

Thank you @Pablichjenkov

[Pablichjenkov]

I mean, try to work on the reasons why you needed to use a paid Gradle service. I have used free Gradle since forever and never had the need to upgrade. But your case might be different.

[Abdhilahi Wabwire]

The cost comes from engineering time + market saturation. The less we ship the less advantage we can take of the market. Having to switch from Gradle to Bazel and considering Maven, greatly increases that cost. More time spent, less code and products shipped. How do you fix a bug if you can't even run a build?

[Abdhilahi Wabwire]

We just need a build system for Kotlin

[Pablichjenkov]

Oh I see, you talk about indirect costs. Well, in such a case I would rather ask in the #gradle channel for the specific problems. I believe if you pay for the enterprise they offer consultancy.

[Abdhilahi Wabwire]

I do not want to pay Gradle directly.

[Pablichjenkov]

I see, well good luck with Maven then.

[Abdhilahi Wabwire]

Thank you. We are trying both Bazel and Maven

[0xf1f1]

what is exactly wrong with using gradle ? Its not that hard to manage and oce its done, you neednt touch it

[Abdhilahi Wabwire]

@0xf1f1 Migrating a Jetpack Compose product to a Compose Multiplatform product has caused the destruction of our entire build flow. We are highly adept at using Gradle and some of our engineers have been using it for over 2 years. Yet this migration has forced us to reconsider using Gradle at all. Bugs, project restructuring, sourceSet management is the worst of these. Adding dependencies to Kotlin sourceSets like commonMain instead of declaring them in the standard dependency structs causes massive bugs everywhere. Even when you declare them in the standard dependency structs, restructuring doesn't fix the problem. Resource sourceSets are broken for Multiplatform builds. It has now been over a week and we still have no fix. Builds have just stopped at our company entirely while we work on this issue. We have had to watch Gradle fail in ever increasingly hilarious ways. The response I'm looking for is a "Yes, we will make a build system for Kotlin or fix Gradle or add better Maven support or Bazel support because we created the language and it is our responsibility" - Instead of defending Gradle like we are all married to it.

[Pablichjenkov]

Two things that might help.
I would consider doing all the multiplatform stuff in a separate branch or even in a separate project and just merge or switch project pipelines when it is fully ready and tested.
Secondly, migrating to a KMP structure within an existing Android project is way more harder than starting from a multiplatform project from zero and then adding the Android pieces little by little. Otherwise, you will be risking whatever you already have working properly.

[Abdhilahi Wabwire]

@Pablichjenkov Yes, this is the exact issue we are having. This is exactly it. It's unbelievable.

[Pablichjenkov]

You have a couple of quick options.
If you know a commit where everything was working well, you can always reset to it.
If the code doesn't have a well defined commit which you can safely go back. I would try creating a new separate kmp project from zero, then place all my Android code in the androidApp module and then keep building the other platforms little by little while my androidApp code stays safe.
I know some articles and YouTubers online have promoted this migration to KMP from within an existing Android app but in my opinion it creates more trouble than what it helps. Way easier and less trouble to start a KMP project from zero and just copy/pasting the Android code.

[Abdhilahi Wabwire]

@Pablichjenkov that is excellent information. Yes, this migration was promoted to us by the Kotlin team but it has been destructive rather than helpful. Reverting back to a previous state may be for the best.

[Pablichjenkov]

Good luck 🤞

[Abdhilahi Wabwire]

Solved the problem. Had to search through every single Multiplatform sample available. This was not easy. We still want a build system for Kotlin. We still feel that XML/YAML/TOML would solve a lot of problems. We still feel that declarative is the best way to go. The problem was with sourceSets, there needs to be an easier way of pointing to sourceSets that are not in standard locations. Gradle gets confused when you don't use the precise syntax and when you do it still looks in the wrong place. We had to write custom logic to fix the problem.

[Arjan van Wieringen]

So this massive problem you have, which you vented with a lot of frustration, is solved within a day? Interesting…

[Abdhilahi Wabwire]

@Arjan van Wieringen I was complaining about this yesterday. That was 6 days into this problem I came back again today to complain a second time.

[Arjan van Wieringen]

Okay, but you solved it by actually reading the docs.

[Arjan van Wieringen]

If 6 days kills your market proposition you need to reconsider your proposition tbh

[Abdhilahi Wabwire]

@Arjan van Wieringen No, we solved it by looking at every single multiplatform sample we could find across the entirety of GitHub. Not just the ones in the documentation. Good day to you good sir.

[Arjan van Wieringen]

Your tone of conversation does not invite anybody to help you. Good luck with getting help by being so aggressive.

[Arjan van Wieringen]

And, after searching every single multillatform repo and finding the solution….. would you care to share what the solution is?

[Abdhilahi Wabwire]

Here is how we fixed it:

sourceSets {
create("android") {
manifest.srcFile("src/android/AndroidManifest.xml")
res.srcDirs("src/android/res")
}

sourceSets {
create("lib") {
java.srcDir("src/lib/kotlin")
resources.srcDir("src/lib/resources")
}

sourceSets {
getByName("android") {
manifest.srcFile("src/android/AndroidManifest.xml")
res.srcDirs("src/android/res")
}
}

sourceSets {
getByName("lib") {
java.srcDir("src/lib/kotlin")
resources.srcDir("src/lib/resources")
}
}

dependencies {
sourceSets.named("lib") {

}
}

Here is where it is missing in the documentation:
• https://developer.android.com/build/build-variants#sourcesets
• https://kotlinlang.org/docs/multiplatform-get-started.html
• https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-samples.html
Because this solution, along with some extra logic, was not in the documentation (including the Gradle documentation), many other solutions were tried because we did not know what the exact problem was. That took days worth of time.

[Abdhilahi Wabwire]

We have a specific project structure that we implemented. Gradle was unable to understand the project structure with Compose Multiplatform. Gradle could not figure out what directory was where or how to share logic between directories. We glued our logic together and created new sourceSets. But in order to do that, we first tried other fixes that didn't work because we had to narrow down the issue. Restructuring the project several times. All this to migrate from Jetpack Compose to Compose Multiplatform and we achieved it with great success, pain and an undocumented solution sitting in someone's GitHub repository:

https://github.com/Baeldung/kotlin-tutorials

[Arjan van Wieringen]

But why didn't you ask this in the #gradle channel? This is pretty normal knowledge that even ChatGPT knows and hardly "reaching the limits with Gradle". And Baeldung is hardle 'someone'.

My first hit on Google: "kotlin android manifest custom location gradle" is https://diamantidis.github.io/tips/2020/07/11/specify-alternative-location-for-android-manifest-xml which explains exactly your solution.

[Abdhilahi Wabwire]

Well Baeldung solved my problem so why should I care? & This solution was not documented & your solution is incorrect for our project structure.

[Arjan van Wieringen]

If my team would spent 6 days on a basic Gradle issue that can be Googled in 1 minute, I'd be worried

[Abdhilahi Wabwire]

We have a custom project structure. Your solution is incorrect. Read again about how we fixed it. We created new sourceSets and glued together custom logic.

[Arjan van Wieringen]

Sigh.... good luck with your mentality in the rest of your life.