import okhttp3.ResponseBody
import okio.Buffer
import okio.Source
import okio.Timeout
import okio.buffer

internal class UnreadableResponseBody(
  private val mediaType: MediaType?,
  private val contentLength: Long,
) : ResponseBody(),
  Source {
  override fun contentType() = mediaType

  override fun contentLength() = contentLength

  override fun source() = buffer()

  override fun read(
    sink: Buffer,

                  override fun peek() = exchange.peekTrailers()

                  override fun get(): Headers {
                    val source = responseBody.source()
                    if (source.isOpen) {
                      source.skipAll()
                    }
                    return peek() ?: error("null trailers after exhausting response body?!")
                  }
                },

# Helper function to copy a srcjar after moving any source files
# directly under the root to the "maven-style" src/main/java layout
#
# Source files generated by annotation processors appear directly
# under the root of srcjars jars created by bazel, rather than under
# the maven-style src/main/java subdirectory.
#
# Bazel manages annotation generated source as follows: First, it

import okhttp3.CompressionInterceptor
import okio.BufferedSource
import okio.Source

/**
 * Support for Zstandard encoding. Use via the [CompressionInterceptor].
 */
object Zstd : CompressionInterceptor.DecompressionAlgorithm {
  override val encoding: String get() = "zstd"

  override fun decompress(compressedSource: BufferedSource): Source = compressedSource.zstdDecompress()

            ArtifactMetadataSource source,
            ArtifactFilter filter,
            List<ResolutionListener> listeners) {
        return collect(
                artifacts,
                originatingArtifact,
                managedVersions,
                localRepository,
                remoteRepositories,
                source,
                filter,
                listeners,

        WARNING //
    }

    /**
     * Gets the hint about the source of the problem. While the syntax of this hint is unspecified and depends on the
     * creator of the problem, the general expectation is that the hint provides sufficient information to the user to
     * track the problem back to its origin. A concrete example for such a source hint can be the file path or URL from
     * which the settings were read.
     *

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same
    Java package; see

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same
    Java package; see

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same
    Java package; see

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same
    Java package; see