-
Notifications
You must be signed in to change notification settings - Fork 10
Closed
Labels
a:enhancementNew feature or requestNew feature or request
Description
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-infothat operate on the classpath, can still have dependencies declared in terms of module names (using the same terminology as in the in themodule-infos of other source sets). In cases where amodule-infodoes exist, there should be an error if these notations are used.
Metadata
Metadata
Assignees
Labels
a:enhancementNew feature or requestNew feature or request