Skip to content

Consider a DSL for dependency declaration in module terminology #31

@jjohannes

Description

@jjohannes

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions