A Gradle plugin to constrain a multi-module build dependency graph.

Meant to enforce an API/Implementation modularisation pattern in a multi-module monolith project:

article Slaying the monolith: API/Implementation modularisation pattern in Android development

by Sean Coyle

Example of the failure when, for instance, implementation tries to depend on another implementation module:

Apply the plugin at the root project:

plugins {
  java
  id("io.github.gmazzo.modulekind") version "<latest>"
}

Then each subproject must be configured with as api or implementation:

moduleKind = "api" // or "implementation" or "monolith"

The plugin introduces a new io.github.gmazzo.modulekind attribute that:

1. Is requested on key resolvable Configurations for known plugins (java and android)
2. Decorates module's Outgoing Variants.
3. Is used by an AttributeCompatibilityRule to determine if is a legal dependency for its consumer

It's recommended to read the Understanding Variant Selection chapter in Gradle's manual for a better understanding.

By default, the plugin will provide the following compatibility table (which can be printed by running moduleKindConstraints task):

These restrictions are fully configurable through the moduleKindConstraints DSL. The following is the equivalent configuration of the table above:

moduleKindConstraints {
  "implementation" compatibleWith "api"
  "monolith" compatibleWith "implementation"
  "monolith" compatibleWith "api" // redundant, since compatibilities are transitive
}

Or in groovy:

moduleKindConstraints {
  compatibility("implementation", "api")
  compatibility("monolith", "implementation")
  compatibility("monolith", "api") // redundant, since compatibilities are transitive
}

Like the demo project, imagine you want to have an extra deep in the 4th levels dependency graph where:

• app is the monolith
• implementation and api are the usual setup
• api can also on domain modules, meant to share domain objects between apis

moduleKindConstraints {
  "api" compatibleWith "domain"
  "implementation" compatibleWith "api"
  "app" compatibleWith "implementation"
}