* methods of the delegate. For example, overriding {@link #get(long, TimeUnit)} alone <b>will
 * not</b> change the behavior of {@link #get()}, which can lead to unexpected behavior. In this
 * case, you should override {@code get()} as well.
 *
 * <p><b>{@code default} method warning:</b> This class does <i>not</i> forward calls to {@code

 * and reduces code duplication across strategy implementations.
 *
 * <p>Strategies work with domtrip Documents for perfect formatting preservation.
 * Subclasses can create domtrip Editors from Documents as needed:
 * <pre>
 * Editor editor = new Editor(document);
 * // ... perform domtrip operations ...
 * // Document is automatically updated
 * </pre>
 */

We utilize nullness annotations in Java code and somewhat rely on IDE warnings to guide us.
However, the Java code we have is not fully annotated, which causes several consequences:
* IDE warnings can be misleading
* Redundant null checks may increase binary size, hurt performance, and increase cognitive load for readers
* Missing null checks may cause NullPointerException
* Bridging with Kotlin code is polluted with platform types

import org.apache.maven.api.annotations.Experimental;

/**
 * Marker interface to indicate services that can be provided by plugins and extensions.
 * <p>
 * This interface serves as the base for all Service Provider Interface (SPI) components in Maven.
 * Classes implementing this interface can be discovered and loaded by Maven through the
 * Java ServiceLoader mechanism, allowing plugins and extensions to contribute functionality

 * Maven provides implementations of those types and may inject them in plugins.
 * <p>
 * A type can be marked {@link Consumer} or {@link Provider} but not both. A type is assumed to be
 * {@link Consumer} if it is not marked either {@link Consumer} or {@link Provider}.
 * <p>
 * A package can be marked {@link Provider}. In this case, all types in the package are considered

 * This script plugin configures formatting for Java source using Spotless
 * for Gradle. Since the act of formatting existing source can interfere
 * with developers' workflows, we don't automatically format all code
 * (yet). Instead, we maintain a list of projects that are excluded from
 * formatting, until we reach a point where we can comfortably format them
 * in one go without too much disruption.
 *

* They are not synced with the code to reflect the eventual solution that is committed
* 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.

sftp>
```

## Advanced options

### Change default FTP port

Default port '8021' can be changed via

```
--ftp="address=:3021"
```

### Change FTP passive port range

By default FTP requests OS to give a free port automatically, however you may want to restrict

                    );
                }

                if (entry.getArea() == null) {
                    throw new GradleException(
                        "[" + path + "] must provide an [area] (only 'known-issue' and " + "'security' entries can omit this"
                    );
                }
            }

 * The implementation should have a <code>Mojo</code> annotation with the name of the goal:
 * <pre>
 *   &#64;Mojo( name = "&lt;goal-name&gt;" )
 * </pre>
 * <p>
 * There are also a number of attributes which can be used to control how and when the
 * <code>Mojo</code> is executed:
 * </p>
 * <table border="1">
 *  <caption>mojo annotation attributes</caption>
 *  <tr>
 *      <th>Descriptor Element</th>