"bulgarian_override": {
          "type":       "stemmer_override",
          "rules_path": "${fess.dictionary.path}bg/stemmer_override.txt"
        },
        "catalan_elision": {
            "type":     "elision",
            "articles": [ "d", "l", "m", "n", "s", "t"]
        },
        "catalan_stop": {
          "type":       "stop",
          "stopwords_path": "${fess.dictionary.path}ca/stopwords.txt"
        },

          "language":   "bulgarian"
        },
        "bulgarian_override": {
          "type":       "stemmer_override",
          "rules": []
        },
        "catalan_elision": {
            "type":     "elision",
            "articles": [ "d", "l", "m", "n", "s", "t"]
        },
        "catalan_stop": {
          "type":       "stop",

          "language":   "bulgarian"
        },
        "bulgarian_override": {
          "type":       "stemmer_override",
          "rules": []
        },
        "catalan_elision": {
            "type":     "elision",
            "articles": [ "d", "l", "m", "n", "s", "t"]
        },
        "catalan_stop": {
          "type":       "stop",

* Google Docs is not a "code-oriented" tool, like Markdown can be
* Review in Google Docs is not as simple as a PR code review in GitHub

## Decision

The *Build Tool Team* has decided to use Architectural Decision Records (aka ADR) to track decisions we want to follow.

The main logic with ADRs is to describe (architectural) decisions made:

What would have happened if Gradle was limited to _only Java 11_ at the time?

## Decision

1. The Gradle distribution will never include a Java runtime.
   Instead, Gradle will leverage Java toolchains for the Daemon and worker processes.

A downside of this structure is that it is difficult to do focused work on the Gradle UI.

## Decision

Introduce a "UI" architecture module to the core platform, and move the user interaction services to this new module.

This includes:

- Logging and progress services.

- **Reduce the size of the Gradle distribution** - We no longer need to carry multiple standard libraries for different languages.

## Decision

We do not introduce new public API methods that include Groovy types in their signatures.
Existing Groovy methods will not be removed immediately.

## Consequences

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

Organize the Gradle code base into a set of coarse-grained "architecture modules".
An architecture module is responsible for providing a coherent set of features and:

it is unlikely that we'll be able to remove `null` entirely.

After migrating to Java 8, we can use pluggable type checkers to ensure that our annotations are consistent, 
and there are no missing null checks.

## Decision

Use "NullAway" in JSpecify mode to check for null-related errors in Java code.

Consider improper uses of `null` detected by NullAway a compilation error (not a warning, and not a separate CI job to test).

- **Type Safety:**
Java serialization does not enforce type safety as strictly as some alternatives, potentially leading to runtime errors.

## Decision

We do not use Java serialization.
Instead, we use custom serialization where we explicitly describe how data objects should be serialized and deserialized.

For internal purposes, we use binary formats for their brevity.