If I have a monorepo of multiple apps depending on...

# gradle

[ursus]

If I have a monorepo of multiple apps depending on many common modules, does it make sense for me to use composite builds, if I want to stay monorepo? Some performance benefit? It seems it's all built from source anyways

And even if there was some build speed, if I were to break apart this one big gradle project into say 3 (per app), and I were to change a common module api, I'd need to open 3 projects (3 IDE instances) and work in the changes, right?

[Zac Sweers]

This has nothing to do with Kotlin, please take it elsewhere

[christophsturm]

you can ask in the gradle slack. my 2 cents:
• you don’t have to change the individual builds to do a composite build
• every build should work on its own
• but a composite build for all of them is also handy, for example if you want do do a big automated refactor.

[ursus]

ill stick with a single build and when ide ram beceomes issue ill just buy more

[ursus]

its better for refactoring etc

[christophsturm]

idea can open the composite build just fine and do refactorings over all the projects

[ephemient]

1. There is a #gradle channel because there are many questions and issues in the intersection of Kotlin and Gradle.
2. JetBrains runs this Slack community and has set out the rules. https://github.com/JetBrains/kotlin-web-site/blob/master/pages/community/slackccugl.md

[Zac Sweers]

Consider reading the code of conduct for this slack group, which specifically calls this out:

Please remember this is a Slack team for Kotlin. If you have generic questions that are about a technology (which may or may not be used with Kotlin), maybe it’s better to use another forum, such as StackOverflow.

This was a part of the larger revamp of community guidelines to improve this community recently due to the large amount of noise from non-kotlin-related posts just like this one.

Why do we even have a gradle channel then?

If you have discussion around KGP, kotlin-dsl, kotlin use in gradle plugins, kotlin integration into gradle projects, etc, all of those are fair game here. This question was about gradle composite builds, which have nothing to do with kotlin. There is a dedicated community slack for gradle that is better suited to this.

If you are truly so angry as to broadcast this complaint back to a channel of 4500 people in what feels like haphazard attempt to publicly shame folks (which is a big issue in the CoC as it could be seen as harassment), consider raising this in a more appropriate venue like #meta, as your writeup suggests you have deeper issues with the recent changes.

[James Whitehead]

If you are truly so angry as to broadcast this complaint back to a channel of 4500 people in what feels like haphazard attempt to publicly shame folks (which is a big issue in the CoC as it could be seen as harassment),

For the record I'm a relative newcomer, so I wasn't aware that there had been a change like this introduced as I don't have historical context of this Slack. And therein lies the issue, is that as a newcomer I haven't observed that this community is particularly warm or welcoming. I'm sorry that my comment was so far out of line that you had to threaten me with harassment. I'll keep my opinion to myself in the future. Have a nice day.

[James Whitehead]

I will also be sure to thoroughly read and re-read the code of conduct so that this doesn't happen again in the future.

[ursus]

Tbh people do this because stackoverflow is dead, not to disobey some rules

[gildor]

@ursus Please, do not continue this offtopic, if you want to discuss code of conduct of this slack, please do this in #meta

[edrd]

While I agree this moderation is important, let's not forget empathy is part of the code of conduct and some people are not posting off-topic questions here on bad faith. Let's try to be helpful and point people to the Gradle slack (even if the channel topic already points them there)