// Test with no roles
        testUser.setRoleNames(new String[] {});
        assertFalse(fessUserBean.hasRoles(new String[] { "admin", "user" }));

        // Test with single role matching one of accepted
        testUser.setRoleNames(new String[] { "admin" });
        assertTrue(fessUserBean.hasRoles(new String[] { "admin", "user" }));
        assertTrue(fessUserBean.hasRoles(new String[] { "guest", "admin" }));

# ADR-0001 - Use Architectural Decision Records

## Status

- ACCEPTED on 2023-12-01

## Context

In a distributed team with many subteams, the best solution to communicate decisions is to use a format accessible by everyone in charge of development.

We use *Specification* and *Discovery* documents stored in Google Drive, but they present some downsides:

        // Threshold of 0 should be accepted
        request.threshold(0);

        assertEquals(0, request.threshold());
    }

    @Test
    public void testThresholdWithNegative() {
        CurlRequest request = new CurlRequest(Method.GET, "https://example.com");

        // Negative threshold should be accepted (though may not make sense)
        request.threshold(-1);

This includes adding the description of the changes to the `accepted-public-api-changes.json` file, and providing a reason for each change.
You can add the changes to any place in the file, e.g. at the top.

3. Make sure the file with accepted changes is sorted.\
Use the `./gradlew :architecture-test:sortAcceptedApiChanges` task to sort the file.

tasks.register<PreparePatchRelease>("preparePatchRelease") {
    group = "Versioning"
    description = "Prepares the repository for a patch release: bumps version.txt, updates released-versions.json, and clears accepted API changes."
    versionFile = layout.projectDirectory.file("version.txt")
    releasedVersionsFile = releasedVersionsFile()
    dependsOn(":architecture-test:cleanAcceptedApiChanges")

# ADR-0005 - Introduce a UI architecture module to the core platform

## Status

- ACCEPTED on 2024-02-07

## Context

The Gradle core platform provides many services to the Gradle platforms and builds logic. One such group of services allows logic to interact with the build user, to provide diagnostics, progress information, prompt for questions, and so on. Currently, these services are part of the core platform runtime architecture module.

   *
   * <p>If the supplied future is {@linkplain #isDone done} when this method is called and the call
   * is accepted, then this future is guaranteed to have been completed with the supplied future by
   * the time this method returns. If the supplied future is not done and the call is accepted, then
   * the future will be <i>set asynchronously</i>. Note that such a result, though not yet known,

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

## Status

- ACCEPTED on 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.

# ADR-0002 - Avoid using Java serialization

## Status

- ACCEPTED on 2023-12-01

## Context

In Gradle we often need to serialize in-memory objects for caching, or to transmit them across process barriers, etc.
Java serialization is one way to implement this, however, despite its simplicity of implementation, it has several drawbacks:

- **Performance:**
Java's built-in serialization mechanism is often slower compared to other serialization solutions.

testing/architecture-test                   @gradle/bt-architecture-council

# These files change frequently, and changes to them don't need to automatically alert the architecture council
testing/architecture-test/src/changes/accepted-changes/accepted-public-api-changes.json
testing/architecture-test/src/changes/archunit-store/internal-api-nullability.txt

# Core automation platform (core/configuration)
platforms/core-configuration/               @gradle/bt-cortex