</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 https://goo.gl/pRV3Yn for details.

    The summary is that it ignores one file in favor of the other.

        <module name="IllegalImport">
            <!--
                We shouldn't use jdk.internal types.
                
                com.beust and org.testng.collections has classes that look like Guava.

                We prefer to import javax.annotation and fully-qualify references to org.jetbrains.annotations.
            -->

  <inherits name="com.google.thirdparty.publicsuffix.PublicSuffixType" />

  <!-- com.google.common.testing.Testing is located in
       GuavaTests under guava-gwt/test -->

  <source path="">
    <include name="ForceGuavaCompilationEntryPoint.java" />
  </source>
  <entry-point class="com.google.common.ForceGuavaCompilationEntryPoint" />

</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 https://goo.gl/pRV3Yn for details.

    The summary is that it ignores one file in favor of the other.

</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 https://goo.gl/pRV3Yn for details.

    The summary is that it ignores one file in favor of the other.

</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 https://goo.gl/pRV3Yn for details.

    The summary is that it ignores one file in favor of the other.

				<include name="dataformat/poi-*" />
				<include name="dataformat/SparseBitSet-*" />
				<include name="dataformat/stax-api-*" />
				<include name="dataformat/xmlbeans-*" />
				<include name="minhash/guava-*" />
				<include name="minhash/failureaccess-*" />
				<include name="minhash/listenablefuture-*" />
			</fileset>
		</delete>
	</target>

  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>com.google.guava</groupId>
    <artifactId>guava-parent</artifactId>
    <version>HEAD-jre-SNAPSHOT</version>
  </parent>
  <artifactId>guava-gwt</artifactId>
  <name>Guava GWT compatible libs</name>
  <description>
    Guava is a suite of core and expanded libraries that include
    utility classes, Google's collections, I/O classes, and

    "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.

    - If users want all of Guava, they depend on guava, which, as of Guava
    27.0, depends on
    listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-...
    version number is enough for some build systems (notably, Gradle) to select

  <parent>
    <groupId>com.google.guava</groupId>
    <artifactId>guava-parent</artifactId>
    <version>HEAD-jre-SNAPSHOT</version>
  </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>