https://kotlinlang.org logo
#gradle
Title
# gradle
j

Jorge Domínguez

02/16/2023, 3:18 PM
I’m currently struggling with something that seems to be related to Gradle. My project structure is as follows:
Copy code
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:
Copy code
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)
s

Sam

02/16/2023, 3:21 PM
I have had this problem. The jars can end up with the same name 🤦. Let me find my fix.
I did something like this:
Copy code
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
.
j

Jorge Domínguez

02/16/2023, 3:25 PM
I see 🤔 where should I put this config?
s

Sam

02/16/2023, 3:25 PM
In the root
build.gradle.kts
. (It’s possible your problem isn’t exactly the same as mine was, but it does sound similar)
j

Jorge Domínguez

02/16/2023, 3:26 PM
let my try it, thanks!
s

Sam

02/16/2023, 3:27 PM
Not sure 🤔
a

Adam S

02/16/2023, 3:31 PM
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
e

ephemient

02/16/2023, 3:34 PM
yes, same names cause issues beyond conflicting jars
don't do it
you can rename projects in settings if you want to keep the directory names
s

Sam

02/16/2023, 3:35 PM
Gradle subprojects shouldn’t have the same name
I’d argue that they should and Gradle should not have bugs, but point taken 😄
a

Adam S

02/16/2023, 3:36 PM
I will absolutely concede that point! I could qualify my statement with “… until Gradle supports it”
e

ephemient

02/16/2023, 3:37 PM
Copy code
include(":client-specific-some-library")
project(":client-specific-some-library").projectDir = file("libraries/project-specific/some-library")
every project is identified by a Maven coordinate
"$group:$name:$version"
, and that conflicts if you reuse project names
there's ways around it but it's kind a core part of how things work…
j

Jorge Domínguez

02/16/2023, 3:42 PM
that’s good to now, if I’m not mistaken this should be placed in
settings.gradle
right?
v

Vampire

02/16/2023, 3:43 PM
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.
e

ephemient

02/16/2023, 3:48 PM
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
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
8 Views