# ADR-0004 - Use a platform-oriented architecture for Gradle

## Date

2024-02-07

## Context

The Gradle code base is essentially a large monolith, without strong internal boundaries.
This has a number of negative effects on productivity, including:

- Unclear ownership of code.
- Difficult to focus on one particular area.
- Unintended coupling between areas of the code, including tests.

## Decision

# ADR-0003 - Avoid introducing Groovy types to public API

## Date

2024-01-12

## Context

Gradle's public API requires equal access from all JVM-based languages.
Kotlin, Groovy, Java, and other JVM-based languages should be able to use the Gradle API without relying on another language's standard library.

Historically, Gradle has shipped with some Groovy types in very prominent APIs.

son {"uid=bobfisher,ou=people,ou=hwengg,dc=min,dc=io":{"version":0,"policy":"consoleAdmin","updatedAt":"2024-09-09T15:59:59.399979442Z"},"uid=dillon,ou=people,ou=swengg,dc=min,dc=io":{"version":0,"policy":"consoleAdmin","updatedAt":"2024-09-09T16:00:03.729549302Z"}}...

  -->

# Gradle platform architecture

Gradle is arranged into coarse-grained components called "architecture modules" and "platforms".
See [ADR4](standards/0004-use-a-platform-architecture.md) for a definition of these terms.

The diagram below shows the current set of architecture modules and platforms:

<!-- This diagram is generated. Use `./gradlew :architectureDoc` to update it -->