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.

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

    </mailingList>
    <mailingList>
      <name>Maven User List</name>
      <subscribe>users******@****.***</subscribe>
      <unsubscribe>users******@****.***</unsubscribe>
      <post>users@maven.apache.org</post>
      <archive>http://mail-archives.apache.org/mod_mbox/maven-users</archive>
      <otherArchives>
        <otherArchive>http://www.mail-archive.com/users@maven.apache.org/</otherArchive>

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

<!--
 | This is the configuration file for Maven. It can be specified at two levels:
 |
 |  1. User Level. This settings.xml file provides configuration for a single user,
 |                 and is normally provided in ${user.home}/.m2/settings.xml.
 |
 |                 NOTE: This location can be overridden with the CLI option:
 |
 |                 -s /path/to/user/settings.xml
 |

        <configuration>
          <excludes>
            <!-- 2. Don't include the source in the jar (since that would let users depend on it from GWT client code, which is compiled from source). -->
            <exclude>**/ForceGuavaCompilation*</exclude>
            <exclude>**/DummyJavadocClass*</exclude>
          </excludes>
        </configuration>
      </plugin>
      <plugin>

            Specifies that this parameter can be configured directly by the user (as in the case of POM-specified
            configuration). This is useful when you want to force the user to use common POM elements rather than
            plugin configurations, as in the case where you want to use the artifact's final name as a parameter. In
            this case, you want the user to modify {@code <build><finalName/></build>} rather

    </mailingList>
    <mailingList>
      <name>Maven User List</name>
      <subscribe>users******@****.***</subscribe>
      <unsubscribe>users******@****.***</unsubscribe>
      <post>users@maven.apache.org</post>
      <archive>http://mail-archives.apache.org/mod_mbox/maven-users</archive>
      <otherArchives>
        <otherArchive>http://www.mail-archive.com/users@maven.apache.org/</otherArchive>

    </mailingList>
    <mailingList>
      <name>Maven User List</name>
      <subscribe>users******@****.***</subscribe>
      <unsubscribe>users******@****.***</unsubscribe>
      <post>users@maven.apache.org</post>
      <archive>http://mail-archives.apache.org/mod_mbox/maven-users</archive>
      <otherArchives>
        <otherArchive>http://www.mail-archive.com/users@maven.apache.org/</otherArchive>

  <name>Guava InternalFutureFailureAccess and InternalFutures</name>
  <description>
    Contains
    com.google.common.util.concurrent.internal.InternalFutureFailureAccess and
    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

	<!-- The components of Behavior. -->
	<component name="userBhv" class="org.codelibs.fess.es.user.exbhv.UserBhv"/>
	<component name="roleBhv" class="org.codelibs.fess.es.user.exbhv.RoleBhv"/>
	<component name="groupBhv" class="org.codelibs.fess.es.user.exbhv.GroupBhv"/>