I’m currently struggling with something that seems...

# gradle

[Jorge Domínguez]

I’m currently struggling with something that seems to be related to Gradle. My project structure is as follows:

project
|____ libraries
     |____ client-specific
     |    |____ some-library
     |____ some-library

There are two versions of some-library, one for client-specific and another one for the whole project. When I try to use both versions of the library in a demo app I have by doing this:

implementation(project(":project:libraries:client-specific:some-library")
implementation(project(":project:libraries:some-library")

it seems that whatever library is declared first is prioritized, so in this case if I try to use the classes in project:libraries:some-library I get all kinds of errors about missing resources that exist in there but not in :project:libraries:client-specific:some-library . But if I use the classes in :project:libraries:client-specific:some-library there are no complains. These classes have same names but different packages. Is there a way to work around this? I need to use both versions (edited)

[Sam]

I have had this problem. The jars can end up with the same name 🤦. Let me find my fix.

[Sam]

I did something like this:

allprojects {
    extensions.findByType<BasePluginExtension>()?.apply {
        archivesName.set(path.replace(":", "-"))
    }
}

The default is to just use the name, so both jars end up being called some-library.jar. With this fix, you’d get libraries-client-specific-some-library.jar and libraries-some-library.jar.

[Jorge Domínguez]

I see 🤔 where should I put this config?

[Sam]

In the root build.gradle.kts. (It’s possible your problem isn’t exactly the same as mine was, but it does sound similar)

[Jorge Domínguez]

let my try it, thanks!

[Jorge Domínguez]

is it related to this? https://github.com/gradle/gradle/issues/847

[Sam]

Not sure 🤔

[Adam S]

There are two versions of some-library

Gradle subprojects shouldn’t have the same name, even if the paths are different

https://stackoverflow.com/a/74607687/4161471

[ephemient]

yes, same names cause issues beyond conflicting jars

[ephemient]

don't do it

[ephemient]

you can rename projects in settings if you want to keep the directory names

[Sam]

Gradle subprojects shouldn’t have the same name

I’d argue that they should and Gradle should not have bugs, but point taken 😄

[Adam S]

I will absolutely concede that point! I could qualify my statement with “… until Gradle supports it”

[ephemient]

include(":client-specific-some-library")
project(":client-specific-some-library").projectDir = file("libraries/project-specific/some-library")

[ephemient]

every project is identified by a Maven coordinate "$group:$name:$version", and that conflicts if you reuse project names

[ephemient]

there's ways around it but it's kind a core part of how things work…

[Jorge Domínguez]

that’s good to now, if I’m not mistaken this should be placed in settings.gradle right?

[Vampire]

I’d argue that they should and Gradle should not have bugs, but point taken

iirc they can, if you use different group values.
Because if the projects have same group and name, then as @ephemient said, they produce the same artifact and thus are conflict-resolved.

[ephemient]

right, you either need to change the name or the group. IMO you might as well change the name and paths so that you don't have nested projects, which leads to classloader inheritance

[ephemient]

btw. even if you set different project.group, if you use the same project.name then by default the output JARs will have the same names, and that will lead to problems with distribution