Multi-module project with sub-modules with same name

Help/Discuss
1

Hello, I’ve got a multi-module project with multiple services that each have a ‘validator’ sub-module. I wanted to use the ‘validator’ module of each service as a dependency on my front-end client to validate changes to the service properties. However, whenever I import the projects in the module, it only imports one of the dependencies (not the other).

services
├── archive-service
│   ├── build.gradle
│   ├── gradle.properties
│   ├── core
│   └── validator
└── copy-service
    ├── build.gradle
    ├── gradle.properties
    ├── core
    └── validator

In the front end service, I added both service validators as dependencies:

dependencies {
    providedCompile project(':services:copy-service:validator')
    providedCompile project(':services:archive-service:validator')
}

The project builds successfully, but it only pulls in the Java code from the copy-service dependency and not from the archive-service. If I reverse their order, then it gets the ‘archive-service’ and not the copy-service. I’ve found a work around, by renaming the module so its unique i.e. rename the copy-service validator -> copy-validator and archive-service validator -> archive-validator. Why can’t gradle use the full name when resolving the project instead of only the final suffix?

1 Like
2

Hi
Solving this problem I’ve found the following issue on github

1 Like
3

Hi @ivan-osipov, thanks for you replying to my issue. I guess this form is not very active since it took a year to reply. Anyway, I did finally sort it out kinda like @ljacomet recommended, by using explicit naming so in my example I used:

implementation project(':services:archive-service:archive-validator')
implementation project(':services:copy-service:copy-validator')

Its not pretty, but it did fix the underlying issue.

4

I tried the approach you metioned above and also an alternative one when you set a unique group like

//archive/build.gradle
subprojects {
    group = "yourrealgroup.arichive"
}
//copy/build.gradle
subprojects {
    group = "yourrealgroup.copy"
}

then decieded to stop at the second option because it is applicable in my case and looks more clear

Glad to see that you’ve found the solution :slight_smile:
Probably gradle team moved all their attention to stackoverflow questions

1 Like