documentation for details on file names, formats, and so on.

 During Maven initialization, Maven tweaks default root logging level to match CLI verbosity choice. Since such feature isn't available
 in SLF4J API, logging implementation specific extensions need to be added into Maven to support these CLI options: see

    /**
     * Gets the problems that were encountered during the model building. Note that only problems of severity
     * {@link ModelProblem.Severity#WARNING} and below are reported here. Problems with a higher severity level cause
     * the model builder to fail with a {@link ModelBuildingException}.
     *
     * @return The problems that were encountered during the model building, can be empty but never {@code null}.
     */

      V v = ((TestMapGenerator<K, V>) mapGenerator.getInnerGenerator()).samples().e0().getValue();
      List<Entry<K, V>> entries = new ArrayList<>();
      for (K element : insertionOrder) {
        entries.add(mapEntry(element, v));
      }

      List<K> keys = new ArrayList<>();
      for (Entry<K, V> entry : mapGenerator.order(entries)) {
        keys.add(entry.getKey());
      }
      return keys;

 * elements, if there is no comparator) to test element equality. As a result, if the comparator is
 * not consistent with equals, some of the standard implementations may violate the {@code Set}
 * contract.
 *
 * <p>The {@code standard} methods and the collection views they return are not guaranteed to be
 * thread-safe, even when all of the methods that they depend on are thread-safe.
 *
 * @author Louis Wasserman

  public Collection<V> removeAll(@Nullable Object key) {
    return MoreObjects.firstNonNull(asMap().remove(key), unmodifiableEmptyCollection());
  }

  @SuppressWarnings("EmptyList") // ImmutableList doesn't support nullable element types
  Collection<V> unmodifiableEmptyCollection() {
    // These return false, rather than throwing a UOE, on remove calls.
    return (unfiltered instanceof SetMultimap) ? emptySet() : emptyList();
  }

   * insertion order.
   */
  private void populateTShapedGraph() {
    putEdge(2, 1);
    putEdge(1, 4);
    putEdge(1, 3);
    putEdge(1, 2); // Duplicate
    putEdge(4, 5);
  }

  // Element Mutation

  @Test
  public void putEdge_existingNodes() {
    assume().that(graphIsMutable()).isTrue();

    // Adding nodes initially for safety (insulating from possible future

   * queue's iterator:
   *
   * {@snippet :
   * Queue<E> queue = Queues.synchronizedQueue(MinMaxPriorityQueue.<E>create());
   * ...
   * queue.add(element); // Needn't be in synchronized block
   * ...
   * synchronized (queue) { // Must synchronize on queue!
   *   Iterator<E> i = queue.iterator(); // Must be in synchronized block
   *   while (i.hasNext()) {

    for (int i = 0; i < elements.length; i++) {
      StackTraceElement element = elements[i];
      if (element.getClassName().equals(clazz) && element.getMethodName().equals(method)) {
        return i;
      }
    }
    throw new AssertionError(
        "Expected element " + clazz + "." + method + " not found in stack trace", e);
  }

    //    were added to the queue. It's easily possible for one thread to take the head of the
    //    queue, immediately followed by another thread taking the next element in the queue. That
    //    second thread can then dispatch to the subscriber it took before the first thread does.
    //
    // All this makes me really wonder if there's any value in queueing here at all. A dispatcher

   * @param data the table data, repeating the sequence row key, column key, value once per mapping
   * @throws IllegalArgumentException if the size of {@code data} isn't a multiple of 3
   * @throws ClassCastException if a data element has the wrong type
   */
  protected abstract Table<String, Integer, C> create(@Nullable Object... data);

  protected void assertSize(int expectedSize) {
    assertEquals(expectedSize, table.size());
  }