assertSame(in, out);
    } else {
      assertEquals(expected, out);
    }
  }

  // Test collapse() a little differently than the rest, as we really want to
  // cover lots of different configurations of input text
  public void testCollapse() {
    // collapsing groups of '-' into '_' or '-'
    doTestCollapse("-", "_");
    doTestCollapse("x-", "x_");
    doTestCollapse("-x", "_x");

      assertSame(in, out);
    } else {
      assertEquals(expected, out);
    }
  }

  // Test collapse() a little differently than the rest, as we really want to
  // cover lots of different configurations of input text
  public void testCollapse() {
    // collapsing groups of '-' into '_' or '-'
    doTestCollapse("-", "_");
    doTestCollapse("x-", "x_");
    doTestCollapse("-x", "_x");

 *
 * <p>The caches produced by {@code CacheBuilder} are serializable, and the deserialized caches
 * retain all the configuration properties of the original cache. Note that the serialized form does
 * <i>not</i> include cache contents, but only configuration.
 *
 * <p>See the Guava User Guide article on <a
 * href="https://github.com/google/guava/wiki/CachesExplained">caching</a> for a higher-level

          <show>package</show>
        </configuration>
      </plugin>
      <!-- Disable "normal" testing, which doesn't work for GWT tests. -->
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <skip>true</skip>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-dependency-plugin</artifactId>

 *   <li>While a dependency on Android ought to be easy if it's for annotations only, it will
 *       probably require adding the dep to various ACLs, license files, and Proguard
 *       configurations, and there's always the potential that something will go wrong. It
 *       <i>probably</i> won't, since the deps are needed only in tests (and maybe someday in
 *       testlib), but why bother?

 *   <li>While a dependency on Android ought to be easy if it's for annotations only, it will
 *       probably require adding the dep to various ACLs, license files, and Proguard
 *       configurations, and there's always the potential that something will go wrong. It
 *       <i>probably</i> won't, since the deps are needed only in tests (and maybe someday in
 *       testlib), but why bother?

 *
 * <p>The caches produced by {@code CacheBuilder} are serializable, and the deserialized caches
 * retain all the configuration properties of the original cache. Note that the serialized form does
 * <i>not</i> include cache contents, but only configuration.
 *
 * <p>See the Guava User Guide article on <a
 * href="https://github.com/google/guava/wiki/CachesExplained">caching</a> for a higher-level

    </resources>
    <plugins>
      <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <archive>
            <manifestEntries>
              <Automatic-Module-Name>com.google.common</Automatic-Module-Name>
            </manifestEntries>
          </archive>
        </configuration>
      </plugin>
      <plugin>
        <extensions>true</extensions>

            </goals>
            <configuration>
              <rules>
                <requireMavenVersion>
                  <version>3.0.5</version>
                </requireMavenVersion>
                <requireJavaVersion>
                  <version>1.8.0</version>
                </requireJavaVersion>
              </rules>
            </configuration>
          </execution>
        </executions>

 *
 * <p>Now {@code MY_SPLITTER.split("foo,,, bar ,")} returns just {@code ["foo", "bar"]}. Note that
 * the order in which these configuration methods are called is never significant.
 *
 * <p><b>Warning:</b> Splitter instances are immutable. Invoking a configuration method has no
 * effect on the receiving instance; you must store and use the new splitter instance it returns
 * instead.
 *
 * <pre>{@code
 * // Do NOT do this