InternalFutures. Most users will never need to use this artifact. Its
    classes are conceptually a part of Guava, but they're in this separate
    artifact so that Android libraries can use them without pulling in all of
    Guava (just as they can use ListenableFuture by depending on the
    listenablefuture artifact).
  </description>
  <build>
    <plugins>
      <plugin>

    conflict with the copy of ListenableFuture in guava itself. If users are
    using an older version of Guava or a build system other than Gradle, they
    may see class conflicts. If so, they can solve them by manually excluding
    the listenablefuture artifact or manually forcing their build systems to
    use 9999.0-....
  </description>
  <build>
    <plugins>
      <plugin>

    <version>HEAD-jre-SNAPSHOT</version>
  </parent>
  <artifactId>guava-tests</artifactId>
  <name>Guava Unit Tests</name>
  <description>
    The unit tests for the Guava libraries - separated into a
    separate artifact to allow for the testlibs to depend on guava
    itself.
  </description>
  <dependencies>
    <dependency>
      <groupId>${project.groupId}</groupId>

              <placement>X</placement>
            </tag>
          </tags>

          <!-- TODO(cpovirk): Move this to the parent after making the package-list files available there. -->
          <!-- We add the link ourselves, both so that we can choose Java 9 over the version that -source suggests and so that we can solve the JSR305 problem described below. -->
          <detectJavaApiLink>false</detectJavaApiLink>
          <offlineLinks>

  </parent>
  <artifactId>guava-testlib</artifactId>
  <name>Guava Testing Library</name>
  <description>
    Guava testlib is a set of java classes used for more convenient
    unit testing - particularly to assist the tests for Guava itself.
  </description>
  <dependencies>
    <dependency>
      <groupId>com.google.code.findbugs</groupId>
      <artifactId>jsr305</artifactId>
    </dependency>
    <dependency>

    that empty artifact over the "real" listenablefuture-1.0 -- avoiding a
    conflict with the copy of ListenableFuture in guava itself. If users are
    using an older version of Guava or a build system other than Gradle, they
    may see class conflicts. If so, they can solve them by manually excluding
    the listenablefuture artifact or manually forcing their build systems to
    use 9999.0-....
  </description>
  <build>

            Some tests need reflective access to the internals of these packages. It is only the
            tests themselves and not the code being tested that needs that access, though there's no
            obvious way to ensure that.

            We could consider arranging things so that only the tests we know need this would get
            the add-opens. Right now that doesn't seem worth the effort, though.
        -->

            the module description of only the prod module. And the prod module doesn't inherit all
            the modules that the test module classes use, so we get errors.

            The good news is that, despite ignoring errors here, GWT does fail if any errors affect
            classes that are actually used in the module under test.

              <placement>X</placement>
            </tag>
          </tags>

          <!-- TODO(cpovirk): Move this to the parent after making the package-list files available there. -->
          <!-- We add the link ourselves, both so that we can choose Java 9 over the version that -source suggests and so that we can solve the JSR305 problem described below. -->
          <detectJavaApiLink>false</detectJavaApiLink>
          <offlineLinks>

    <version>HEAD-android-SNAPSHOT</version>
  </parent>
  <artifactId>guava-tests</artifactId>
  <name>Guava Unit Tests</name>
  <description>
    The unit tests for the Guava libraries - separated into a
    separate artifact to allow for the testlibs to depend on guava
    itself.
  </description>
  <dependencies>
    <dependency>
      <groupId>${project.groupId}</groupId>