gradlex-org/java-module-dependencies

Consider a DSL for dependency declaration in module terminology

Closed this issue · 0 comments

For some projects, there remains the need to define module dependencies in build.gradle files for everything that cannot be expressed in a module-info.java. Right now, the most elegant notation we have is this:

dependencies {
  javaModuleDependencies {
    annotationProcessor(gav("dagger.compiler"))

    testImplementation(gav("org.mockito"))
  }
}

This is still a bit verbose and the gav(...) here can be misleading. Also, this is operating on the javaModuleDependencies extension, which contains all the configuration methods that are for use in convention plugins and not in build script.

It would be nice to have a more compact DSL only for declaring dependencies for "modules". Something like:

modules {
  module(sourceSet.test) {
    annotationProcessor("dagger.compiler")
    runtimeOnly("org.slf4j.simple")
  }
  module(sourceSet.test) {
    requires("org.mockito") // Do we need that? Or better use 'org.gradlex.java-module-testing'?
  }
}
  • There could be explicit keywords for everything that cannot be expressed in module-info:
    runtimeOnly, annotationProcessor (something else?)
  • There could be keywords for everything that can be expressed in module-info – like requires(...) – so that source sets without module-info that operate on the classpath, can still have dependencies declared in terms of module names (using the same terminology as in the in the module-infos of other source sets). In cases where a module-info does exist, there should be an error if these notations are used.