where:
        apiElement | jApiTypeName
        'method'   | 'jApiMethod'
        'field'    | 'jApiField'
    }

    def "new incubating API does not fail the check but is reported"() {
        given:
        def rule = withContext(new NewIncubatingAPIRule([:]))

        when:
        jApiMethod.annotations >> [incubatingAnnotation]
        def violation = rule.maybeViolation(jApiMethod)

      for (String message : expectedMessages) {
        assertThat(expected).hasMessageThat().contains(message);
      }
      return;
    }
    fail("expected failure not reported");
  }

  private static class ForwardingRunnable implements Runnable {

    private final Runnable runnable;

    ForwardingRunnable(Runnable runnable) {
      this.runnable = runnable;
    }

  val oldName = currentThread.name
  currentThread.name = name
  try {
    block()
  } finally {
    currentThread.name = oldName
  }
}

/** Returns the Content-Length as reported by the response headers. */
internal fun Response.headersContentLength(): Long = headers["Content-Length"]?.toLongOrDefault(-1L) ?: -1L

/** Returns an immutable wrap of this. */
@Suppress("NOTHING_TO_INLINE")

        resp.command = ServerMessageBlock.SMB_COM_NT_CREATE_ANDX;
        resp.isExtended = true;

        byte[] buf = new byte[256];
        buf[33] = 34; // baseline wordCount reported by server
        buf[34] = (byte) 0xFF; // no further andx
        // byteCount at 33 + 1 + 34*2 = 102
        ServerMessageBlock.writeInt2(0, buf, 102);

        int n = resp.decode(buf, 0);

 *
 * <p>The one downside of {@code Stopwatch} relative to {@link System#nanoTime()} is that {@code
 * Stopwatch} requires object allocation and additional method calls, which can reduce the accuracy
 * of the elapsed times reported. {@code Stopwatch} is still suitable for logging and metrics where
 * reasonably accurate values are sufficient. If the uncommon case that you need to maximize
 * accuracy, use {@code System.nanoTime()} directly instead.
 *

                try {
                    fixTimestamp(file, readMetadata(file), repositoryMetadata.getMetadata());
                } catch (RepositoryMetadataReadException e) {
                    // will be reported via storeInlocalRepository
                }
            }
        } else {
            // It's a POM - we don't need to retrieve it first
            file = new File(

    }

    private void throwDockerRequiredException(final String message, Exception e) {
        throw new GradleException(
            message + "\nyou can address this by attending to the reported issue, or removing the offending tasks from being executed.",
            e
        );
    }

    /**
     * Runs a command and captures the exit code, standard output and standard error.
     *

 *
 * <p>The one downside of {@code Stopwatch} relative to {@link System#nanoTime()} is that {@code
 * Stopwatch} requires object allocation and additional method calls, which can reduce the accuracy
 * of the elapsed times reported. {@code Stopwatch} is still suitable for logging and metrics where
 * reasonably accurate values are sufficient. If the uncommon case that you need to maximize
 * accuracy, use {@code System.nanoTime()} directly instead.
 *

	// Replication latency information
	Latency ReplicationLatency `json:"replicationLatency"`
	// bandwidth limit for target
	BandWidthLimitInBytesPerSecond int64 `json:"limitInBits"`
	// current bandwidth reported
	CurrentBandwidthInBytesPerSecond float64 `json:"currentBandwidth"`
	// transfer rate for large uploads
	XferRateLrg *XferStats `json:"-" msg:"lt"`
	// transfer rate for small uploads

If the intention is to gather user feedback on an early prototype, then the experimental property should be used.
If the intention is to allow an issue reporter to get additional local diagnostics when running a build in their proprietary environment, then the internal property is sufficient.

Examples of properties that follow the naming rules: