i see.. what should i do for a multi module projec...
# gradle
n
i see.. what should i do for a multi module project ? i want to not redeclar adependencies in every module but i also do not want to leak them fro mthe library
g
You should redeclare dependencies only if you actually use those dependencies in this module and this is reasonable explicit approach. Use implementation when it's possible to better encapsulation of modules
j
@Nikky You could use a for loop.
n
how is a loop going to work for dependencies ?
j
@Nikky
Copy code
val configurationsToConfigure =
    setOf(configurations["config1"], configurations["config2"])

dependencies {

   val dependency = create("some.dependency.here:somename:someversion)

   configurationsToConfigure.forEach {
       (it)(dependency)
    }
}
n
interesting but i feel liek that does not solve my problem of wanting to have dependencies transitibvely available within the lib across modules but not bleeding them outside
j
Across multiple subprojects you mean?
n
but the alternative is to have a lot of duplicatiuion.. or a dependency net
yeah
j
@Nikky In your root project
build.gradle.kts
file:
Copy code
val projectsToConfigure = setOf(project(":A"), project(":B"))

configure(projectsToConfigure) {

    dependencies {
        "compile"("some.dependency.here:somename:someversion")
    }
}
n
i see, that is smart i thought of doing something where i do
Copy code
allpprojects { configureDependencies() }
and then a
when
going over all subprojects to set up dependencies
and for dependencies on projects it can do a recursive call to set up all dependencies then i can organize it later.. since its all in one file
j
Yea, that works. Your root project generally doesn’t have any source code, so you probably want to use:
Copy code
subprojects { configureDependencies() }
n
i organized it so it has sourcecode
i should probably change that
j
I recommend not putting source code in your root project when you have a multi-project build.
1
n
i honestly do not remember why i did organize it that way, i guess rethinking the multimodule layout goes on the todo
g
wanting to have dependencies transitibvely available within the lib across modules
Could you explain your case?