Okay, so I have the subprojects with same names is...

# gradle

[Arjan van Wieringen]

Okay, so I have the subprojects with same names issue (e.g. librariesuicompose and featuresfoocompose) and 'solved' it via code linked in the GitHub issue (https://github.com/gradle/gradle/issues/847):

subprojects {
    val subGroup = path.replace(':', '.').replace('-', '_')
    group = "${rootProject.group}$subGroup"
}

But of course, if I would have read a little further I would have read that this causes issues with the distribution plugin, because you get conflicting JAR names in the lib directory. But I see no solution there. Does anyone know of a way on how to solve this? I can not find out how to change the jar name in 'bulk'.

Otherwise I think I just have to revert to having them named: library-ui-compose, and feature-foo-compose and deal with the awkward UI experience in IntelliJ. I really like having deep folder structures., but alas.

[ephemient]

this will let you keep your existing directory structure while flattening the project names so they are fully distinct:

// settings.gradle.kts
include(":library-ui-compose", ":feature-foo-compose")
project(":library-ui-compose").projectDir = file("library/ui/compose")
project(":feature-foo-compose").projectDir = file("feature/foo/compose")

you could even automate it by iterating over rootProject.children

[Arjan van Wieringen]

Yeah, I will be doing that. I just dislike missing the hierarchy in the gradle panel in IntelliJ, and missing the indication of gradle projects in the project directory structure in IntelliJ. But one has to choose one or the other I suppose.

[Chris Lee]

This is what we use (in addition to similar code for setting group) to have distinct JAR names:

tasks.withType<Jar>().configureEach {
    val newName = project.path.replace(":", "-").drop(1)
    archiveBaseName.set("app-$newName")
}

[ephemient]

that helps if you're building a distribution from local sources, but any external consumers (such as via Maven) will still run into naming collisions when they distribute

[Chris Lee]

correct, it targets use of distribution but doesn’t solve beyond that.

[Arjan van Wieringen]

I think the best course of action would be to not work around the issue of Gradle and actually just name the projects in a way they don’t collide

[Vampire]

How about

// settings.gradle.kts
include(":libraries:ui:library-ui-compose", ":features:foo:feature-foo-compose")
project(":libraries:ui:library-ui-compose").projectDir = file("library/ui/compose")
project(":features:foo:feature-foo-compose").projectDir = file("feature/foo/compose")

?

[Arjan van Wieringen]

That’s also a solution. Lots of doubling though.

[ephemient]

you don't have to write the full path with double components,

val projectDirs = setOf(
    "library/ui/compose",
    "feature/foo/compose",
)
for (dir in dirs) {
    val path = dir.substringBeforeLast('/', "").replace('/', ':') + ':' + dir.replace('/', '-:)
    include(path)
    project(path).projectDir = file(dir)
}

[Arjan van Wieringen]

No, but to include such a subproject as a dependency you get libraryui:library-ui-compose , which is a bit redundant. Still, I keep the hierarchy