Gradle assigns wrong project dependency when parent and last child has same name

We’re having compile issues between projects with inter-project dependencies where gradle is doing some sort of substitution of the dependent project with the compiling project.
My settings.gradle'International’
include 'Versioned’
include 'Translation’
include 'Translation:Versioned’
include 'Translation:SDL:Cloud’
include ‘Translation:SDL:Cloud:Versioned’
include ‘Translation:SDL:TMS’
include ‘Translation:SDL:TMS:Versioned’

The projects Translation:SDL:Cloud:Versioned and Translation:SDL:TMS:Versioned both depend on amongst others the project Translation:Versioned.
Both these projects fail to compile with missing dependencies for Translation:Versioned.

compile (


and running with -d/–debug I can see the classpath includes:


The second jar is incorrect as its the jar of the project thats actually being compiled. Instead it should be


If I run:

gradle :Translation:SDL:Cloud:Versioned:dependencies

I’m seeing instead of a full dependency graph for the Translation:Versioned project this shortcut:

— project :Translation:Versioned -> project :Translation:SDL:Cloud:Versioned (*)

What does this shortcut mean? The (*) as noted that it has appeared before does not appear before.

The only way out of this was to rename the last child project (as a test) to Versioned2 so my settings.gradle looks like this:'International’
include 'Versioned’
include 'Translation’
include 'Translation:Versioned’
include 'Translation:SDL:Cloud’
include 'Translation:SDL:Cloud:Versioned2’
include 'Translation:SDL:TMS’
include ‘Translation:SDL:TMS:Versioned2’

Then everything compiles as expected.

Why is gradle invalidly changing the project dependency from another project to the compiling project? As said above the
’Translation:SDL:Cloud:Versioned’ is a valid project and so is ‘Translation:Versioned’ which is a dependent project, but gradle seems to be substituting the longer/lower one for the short/higher one.

1 Like

This was true for 2.4, 2.5 and 2.6-rc-2

hmm. have you declared groupIds for your project? Gradle most likely identifies dependencies by its FQN (full qualified name, which is “groupId+project name”. Can you try to set different groupIds for projects with the same name in your multiproject build? just wondering if that solves your issue. Nevertheless I can see this is confusing behaviour as you declare the project by path and not by FQN.

1 Like

That does work if I set the failing projects group to something different.
However we have this config in the root build.gradle:"com.mycompany"

allprojects {
group =
version = rootProject.version
timestamp = rootProject.timestamp


By changing the group on a lower level project works i.t.o compilation but creates a separate group, whereas we want to keep the same group across all gradle projects in this code project. Is this still considered a bug or would we have to manipulate the pom generation so as not to interfere with the other gradle/classpath stuff as the correct way if wanting the same group across all projects ?

I’ve resolved it by giving the 2 lower projects a unique group that overrides the root, but then added it back in the maven config:

pom.whenConfigured {pom ->

All compiles and maven installs all with same group.
Thanks for the pointer!

One question about your setup. if you publish different projects with the same group:projectname combination, how does that work when resolving the artifacts from your maven repository?

We actually use the same groupId across all our software projects (repositories). Within that the artifactId is set to the same as the archivesBaseName. The archivesBaseName has the same prefix (acronym for main project) for all gradle projects in the same software project/repository. The rest of the archivesBaseName for subprojects is then simply:
archivesBaseName=project.parent.archivesBaseName+"-" and can be overridden specifically in any sub project if the generated name is not suitable. All subprojects use the same root version and get released together.
In Maven we can then see all the generated dependencies grouped together by the root project archivesBaseName.
So everything is unique and easily resolvable.

Thanks for explaining, I just wanted to check your uploaded projects
have unique maven coordinates.