</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>${project.version}</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <!-- *not* <scope>test</scope>; <scope>compile</scope> is right so that guava-testlib users get junit transitively. -->
      <version>4.13.2</version>
    </dependency>
    <dependency>
      <!--
      Do not include Truth in non-test scope! Doing so creates a problematic dependency cycle.

      <version>${project.version}</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <!-- *not* <scope>test</scope>; <scope>compile</scope> is right so that guava-testlib users get junit transitively. -->
      <version>4.13.2</version>
    </dependency>
    <dependency>
      <!--
      Do not include Truth in non-test scope! Doing so creates a problematic dependency cycle.

          <sourcepath>doesnotexist</sourcepath>
          <!-- Note that we do need to build Javadoc for *some* class. Otherwise, we get an empty Javadoc jar, which the Sonatype repository manager rejects. To avoid that, we've introduced a dummy class. But we made it package-private so that no one can depend on it. That in turn forced us to configure Javadoc to show package-private APIs. -->
          <show>package</show>

            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.
        -->
        <test.add.opens>

    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>