Question: splitting dependencies

[eyJhb]

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!!

[tadfisher]

@eyJhb There are a few reasons that combine to force us to do this:

• Gradle resolves artifacts independently for each of these scopes, using a potentially different set of configured resolvers.
• The resulting classpath is also independent for each of these scopes.
• Gradle allows specifying changing artifacts, such as version ranges (e.g. 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.