I've started to modularize a project, but since th...

# gradle

[jhiertz]

I've started to modularize a project, but since then I've been unable to configure the build of another project that uses this one as a dependency.

I have two projects on different repo. Project A is dependent on project B

// build.gradle.kts (Module :android Project 1)
implementation("projectB:version")

// settings.gradle.kts (Project A)
includeBuild(path_to_projectB) {
    dependencySubstitution {
        substitute(module("projectB")).using(project(":android_sdk"))
    }
}

In my project B I had a single module :android_sdk and everything worked fine. While I'm developing, I can see projects A and B in Android Studio and make modifications, then when I create a release, it uses the version published on a maven. Where things get complicated is when I try to create modules in Project B, I can't use them in Project A.

I tried to include it this way but got an error in the projectB module "Plugin [id: 'com.android.library'] was nout found in any of the following sources

// build.gradle.kts (Module :android Project 1)
implementation(project(":core-util"))

// settings.gradle.kts (Projet A)
includeBuild("${path_to_projectB}/core-util")

If I have to summarize my tree structure, here it is:

Project A
├── build.gradle.kts
├── settings.gradle.kts
├── :android
       ├── build.gradle.kts
Project B
├── build.gradle.kts
├── settings.gradle.kts
├── :android_sdk
       ├── build.gradle.kts
├── :core-util
       ├── build.gradle.kts

I can't access the core-util module from project A even though I'm accessing the android_sdk module.

[Vampire]

You cannot includeBuild the core-util directory, it is a project not a build. Assuming you include the core-util inside the settings script of "Project B", then includeBuild of "Project B" is the appropriate to do and enough. Optimally, you configure your projects in "Project B" properly, so that you do not need any substitution rules, then it just works ootb.

[jhiertz]

In my B project, I have this configuration working:

// settings.gradle.kts
include(":android_sdk")
include(":core-util")

// build.gradle.kts
implementation(project(":core-util"))

But if I try to use a core-util method in project A, I get an Unresolved reference: method and Android Studio suggests I add the core-util module dependency.

When I add the dependency

implementation(project(":core-util"))

I get: org.gradle.api.UnknownProjectException: The project with path ':core-util' could not be found in project ':android'.

[Vampire]

You cannot depend on a project of an included build with project(...), that only works within the same build. You need to use the coordinates.

[jhiertz]

First, thanks for your time, but I can't figure it out sorry.

Without dependencySubstitution I can't use the changes I make to project B in project A. This is because it uses the version currently on maven, which is normal.

But in this dependencySubstitution, I indicate to use the :android_sdk module, which isn't enough now that the project has several modules.

[Vampire]

You can use multiple substitution rules.
But really, if you need any substitution rules imho the better thing to do is to fix the project information of the included build.
If you do not do things like manipulating the coordinates where a project is published to in the publication settings, you should not need any substitution rules.
If you need manual substitution rules, it is more a sign that the included build is not set up idiomatically.
If you include a foreign build on which you do not have direct influence using substitution rules might be the way to go, but if it is a project you have under your control, I would instead fix up that project.

The version is irrelevant.
An included build is always preferred, no matter what version you depend on, you could even depend without version and it would also work.
It is all about the included build being configured properly, or if not possible the correct substitution rules defined.

[jhiertz]

Okay, thanks for the information. Since we have control over project B, I'll look into configuring it correctly so that it can be used simply with an includeBuild.