<name>Guava ListenableFuture only</name>
  <description>
    An empty artifact that Guava depends on to signal that it is providing
    ListenableFuture -- but is also available in a second "version" that
    contains com.google.common.util.concurrent.ListenableFuture class, without
    any other Guava classes. The idea is:

    - If users want only ListenableFuture, they depend on listenablefuture-1.0.

              <location>https://docs.oracle.com/javase/9/docs/api/</location>
            </offlineLink>
            <!-- The Checker Framework likewise would claim javax.annotations, despite providing only a subset of the JSR305 annotations, so it must likewise come after JSR305. -->
            <offlineLink>
              <url>https://checkerframework.org/api/</url>

      </dependency>
      <!--
      We moved away from using dependencyManagement for test-only deps because of https://github.com/google/guava/issues/6654.
      We could probably have resumed it after https://github.com/google/guava/pull/6664.
      But it's always weird that published poms reference test-only libraries at all, so I'm not in any rush to do so.
      -->
    </dependencies>
  </dependencyManagement>

              <location>https://docs.oracle.com/javase/9/docs/api/</location>
            </offlineLink>
            <!-- The Checker Framework likewise would claim javax.annotations, despite providing only a subset of the JSR305 annotations, so it must likewise come after JSR305. -->
            <offlineLink>
              <url>https://checkerframework.org/api/</url>

  <version>1.0</version>
  <name>Guava ListenableFuture only</name>
  <description>
    Contains Guava's com.google.common.util.concurrent.ListenableFuture class,
    without any of its other classes -- but is also available in a second
    "version" that omits the class to avoid conflicts with the copy in Guava
    itself. The idea is:

    - If users want only ListenableFuture, they depend on listenablefuture-1.0.

            and .java files in c.g.c.collect.testModule, one that it doesn't[*]. Consequently,
            c.g.c.base.testModule transitively pulls in .java files from both modules while reading
            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.