When I look at this file I immediately have questi...

# gradle

[Robert Menke]

When I look at this file I immediately have questions that I don’t know the answer to like where is this recursive call even being used is List<*> -> it.addTo(configuration)? Which versions of these dependencies are you using? Why does the configuration function accept any? I realize you probably have good answers to those questions, but I don’t think there’s any reason to complicate dependency specs.

[Czar]

Sure, I probably have to provide some context. All the versions are defined in one place in buildSrc, the recursive all is there so that I can group dependencies which do not make sense separately from each other within the project, e.g. Here are some snippets from DepManagement.kt file which resides in buildSrc

object Versions {
	const val gradle = "4.7-rc-2"
	const val kotlin = "1.2.31"
	const val springBoot = "2.0.1.RELEASE"
	const val springDepManagement = "1.0.5.RELEASE"
	const val kotlinLogging = "1.4.6"
	const val swaggerVersion = "2.7.0"
}
object Deps {
	val swagger = listOf(
		"io.springfox:springfox-swagger2:${Versions.swaggerVersion}",
		"io.springfox:springfox-swagger-ui:${Versions.swaggerVersion}"
	)
// ...
}

[Czar]

This doesn't make much sense when we're talking simple project, but this is actually my playground before moving all this to a large enterprise project which is structured like
root
/|\
c1, c2 ... cN
/|\
p1, p2 ... pN

defining dependencies in that structure without centralized version declaration and auto-complete is huge pain in the nether regions.
So, is your assessment the same, knowing this context?

[Robert Menke]

I may still not fully understand, but I still think that grouping them logically in a single file with clear comments above logically grouped dependencies is the way to go. It sounds like your project may not allow for centralized dependency management, but I’d probably suggest looking at monorepo or project monorepo design so that your dependency management can be more sane in the long term. In the short term I do realize that sometimes we have to add some complexity to handle our own sanity… I guess as long as you have tests and good documentation this approach is fine. Once I saw your DepManagement.kt file I understood what was going on much more clearly 🙂.

[Czar]

Thanks for taking the time 🙂 That's exactly the case for each project on p layer there's only one build file (or subproject section in c layer build file) which details dependencies for that particular project by using values from DepManagement.kt That way each project gets what it needs and all versions are synchronized between all projects.