Source dependency 2-step generation needed for non-Gradle projects

Help/Discuss
1

I recently saw the https://blog.gradle.org/introducing-source-dependencies blog post. The idea of using source dependencies is awesome. I’m looking forward to the ability to use other dependency types more natively from Gradle, especially when trying to combine polyglot projects.

One issue I see now from the example at https://github.com/gradle/native-samples#application-uses-libraries-that-are-not-built-by-gradle-injected-plugins is the 2-step approach needed to first generate the repositories, and then the build setup from settings.gradle seems to kick in. Wouldn’t it be better if the generateRepos step wasn’t needed?

For example, in Bazel this is modeled using the new_* category of methods to declare dependencies and then also allow for the “enclosing” build to declare the build script for the dependency type. For example, from https://docs.bazel.build/versions/master/external.html#non-bazel-projects :

new_git_repository(
    name = "my_ssl",
    remote = "http://example.com/openssl/openssl.git",
    tag = "v1.0.2",
    build_file_content = """
cc_library(
    name = "openssl-lib",
    srcs = ["src/openssl.cc"],
    hdrs = ["src/openssl.h"],
)""",
)
2

You misunderstood the sample - They all live in the same repository, so in order to demonstrate cross-repo dependencies we need to generate a mock repository. If your projects actually are in the same repo, you’d simply use a normal composite build instead of source dependencies.