* They are not synced with the code to reflect the eventual solution that is committed
* Google Docs is not a "code-oriented" tool, like asciidoc 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:

## Architecture Standards

**Experimental!**

We'd like to capture our architectural decisions about the build tool as [Architectural Decision Records (ADRs)](https://adr.github.io/).
For now we just have this global repository of ADRs.
If we see fit, we can break these out to per-platform ones, or keep a hybrid approach to having global and platform-specific ADSs.

Our aim is to keep the process lightweight and approachable.

}{
	{ // 1.
		name: "empty string",
		dsc:  "",
		expDsc: ReplicateDecision{
			targetsMap: map[string]replicateTargetDecision{},
		},
		expErr: nil,
	},

	{ // 2.
		name:   "replicate decision for one target",
		dsc:    "arn:minio:replication::id:bucket=true;false;arn:minio:replication::id:bucket;id",
		expErr: nil,
		expDsc: ReplicateDecision{
			targetsMap: map[string]replicateTargetDecision{

 * object). So it is important to not call {@link #dispatch} while holding any locks. This is why
 * {@link #enqueue} and {@link #dispatch} are 2 different methods. It is expected that the decision
 * to run a particular event is made during the state change, but the decision to actually invoke
 * the listeners can be delayed slightly so that locks can be dropped. Also, because {@link
 * #dispatch} is expected to be called concurrently, it is idempotent.
 */

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.

## Architecture decision records (ADRs)

The Gradle team uses ADRs to record architectural decisions that the team has made.

See [Architecture decisions records](standards) for the list of ADRs.
Be aware these are very technical descriptions of the decisions, and you might find the documentation below more useful as an introduction to the internals of Gradle.

	// VersionPurgeStatuses holds the internal
	VersionPurgeStatuses string `xml:"VersionPurgeStatuses"`
	// ReplicateDecisionStr stringified representation of replication decision
	ReplicateDecisionStr string `xml:"-"`
}

// createBucketLocationConfiguration container for bucket configuration request from client.
// Used for parsing the location from the request body for Makebucket.

- **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.

- **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.

## Status

ACCEPTED

## 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: