* insists upon doing. It then runs the test, which behaves exactly like this package's existing
   * PackageSanityTests. (The test would run on the JVM, too, if not for the suppression below, and
   * that would be a problem because it violates small-test rules. Note that we strip the
   * suppression externally, but it's OK because we don't enforce test-size rules there.)
   *

        with:
          # For discussion, see the first setup-java block.
          # The publish-snapshot workflow doesn't run tests, so we don't have to care which version Maven would select for that step.
          java-version: 25
          distribution: 'temurin'
          cache: 'maven'
          server-id: central
          server-username: CI_DEPLOY_USERNAME

 * This is not correct as it should do this with the built distribution instead.
 *
 * Doing it correctly would require running a Gradle build with the full
 * distribution and extracting the generated api jar from its Gradle user home,
 * slowing down building documentation.
 *
 * All this would be so much simpler if the Kotlin extensions to the Gradle API
 * were generated at build time instead.
 *

Now, let's see how you could use that to return a custom response.

Let's say that you want to return an [XML](https://en.wikipedia.org/wiki/XML) response.

You could put your XML content in a string, put that in a `Response`, and return it:

    "groups" : [ {
      "testProject" : "largeJavaMultiProject",
      "comment" : "We only test the multi-project here since for the monolithic project we would have no cache hits. This would mean we actually would test incremental compilation.",
      "coverage" : {
        "per_commit" : [ "linux" ]
      }
    } ]
  }, {

                    that `password`.
                * Validation: whatever you return will be serialized with the
                    `response_model`, converting any data as necessary to generate the
                    corresponding JSON. But if the data in the object returned is not
                    valid, that would mean a violation of the contract with the client,

    for (int i = 0; i < 8; i++) {
      limiter.acquire(); // // #4
    }
    stopwatch.sleepMillis(500); // #5: to repay for the last acquire
    stopwatch.sleepMillis(2000); // #6: didn't get cold! It would take another 2 seconds to go cold
    for (int i = 0; i < 8; i++) {
      limiter.acquire(); // #7
    }
    assertEvents(
        "R0.00, R1.38, R1.13, R0.88, R0.63, R0.50, R0.50, R0.50", // #1

    for (int i = 0; i < 8; i++) {
      limiter.acquire(); // // #4
    }
    stopwatch.sleepMillis(500); // #5: to repay for the last acquire
    stopwatch.sleepMillis(2000); // #6: didn't get cold! It would take another 2 seconds to go cold
    for (int i = 0; i < 8; i++) {
      limiter.acquire(); // #7
    }
    assertEvents(
        "R0.00, R1.38, R1.13, R0.88, R0.63, R0.50, R0.50, R0.50", // #1

      Object candidateKey = entry.getKey();

      /*
       * Assume that equals uses the == optimization when appropriate, and that
       * it would check hash codes as an optimization when appropriate. If we
       * did these things, it would just make things worse for the most
       * performance-conscious users.
       */
      if (key.equals(candidateKey)) {
        return entry.getValue();
      }

            //
            // If we were to cancel taskFuture, that would let the next task start while the old
            // one is still running.
            //
            // Now, maybe we could tweak our implementation to not start the next task until the
            // callable actually completes. (We could detect completion in our wrapper
            // `AsyncCallable task`.) However, our contract also promises: