Consider a DSL for dependency declaration in module terminology
Closed this issue · 0 comments
jjohannes commented
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
– likerequires(...)
– so that source sets withoutmodule-info
that operate on the classpath, can still have dependencies declared in terms of module names (using the same terminology as in the in themodule-info
s of other source sets). In cases where amodule-info
does exist, there should be an error if these notations are used.