Open eyJhb opened 4 years ago
@eyJhb There are a few reasons that combine to force us to do this:
com.foo:bar:1.+
) or snapshots (com.foo:bar:1.0.0-SNAPSHOT
).To give a concrete example, say you have two repositories, repoA
and repoB
, with the following contents:
repoA
: com.foo:bar:1.0
repoB
: com.foo:bar:1.1
The project then uses the following build script:
buildscript {
repositories {
repoA()
}
dependencies {
classpath("com.foo:bar:1.+")
}
}
repositories {
repoB()
}
dependencies {
implementation("com.foo:bar:1.+")
}
When Gradle configures this project, the buildscript classpath
configuration will contain the JAR from com.foo:bar:1.0
, and the project's implementation
configuration will contain the JAR from com.foo:bar:1.1
.
If we combine all dependencies into a single offline repo when building with Nix, we will obtain a different result than what Gradle built, because Gradle will find the latest matching version in our offline repo for both scopes, which ends up being com.foo:bar:1.1
in the buildscript classpath, meaning we are now building the project using a different set of inputs than what the project is actually requesting (at the time you run gradle2nix
, anyway).
I hope this helps explain the design decision to set up separate offline repos per scope.
Is there any reason why the dependencies are split up into project and then buildscript, plugin and project? Having them in a single dependencies list would yield the same result, but simplify multiple things (I am guessing).
Also, huge thanks for this project!!