* Sadly this mechanism does not translate into maven pom generation. In order
     * to effectively make the pom act as if it has no transitive dependencies,
     * we must exclude each transitive dependency of each direct dependency.
     * <p>
     * Determining the transitive deps of a dependency which has been resolved as
     * non-transitive is difficult because the process of resolving removes the

      if ($submitButton.length > 0) {
        $submitButton.closest("form").trigger("submit");
      }
      return false;
    }
  });

  $(".table tr[data-href]").each(function() {
    var $row = $(this);
    $row.css("cursor", "pointer")
      .on("mouseenter", function() {
        $(this).addClass("active");
      })
      .on("mouseleave", function() {

    extends AbstractSetMultimap<K, V> implements SortedSetMultimap<K, V> {
  /**
   * Creates a new multimap that uses the provided map.
   *
   * @param map place to store the mapping from each key to its corresponding values
   */
  protected AbstractSortedSetMultimap(Map<K, Collection<V>> map) {
    super(map);
  }

  @Override
  abstract SortedSet<V> createCollection();

  @Override

import java.util.List;
import java.util.Map;
import org.jspecify.annotations.Nullable;

/**
 * Implementation of {@code Multimap} that uses an {@code ArrayList} to store the values for a given
 * key. A {@link HashMap} associates each key with an {@link ArrayList} of values.
 *
 * <p>When iterating through the collections supplied by this class, the ordering of values for a
 * given key agrees with the order in which the values were added.
 *

- To be able to reliably use S3 multipart APIs feature of the SDKs without re-inventing the wheel of pre-signing the each URL in multipart API. This is very tedious to implement with all the scenarios of fault tolerance that's already implemented by the client SDK. The general client SDKs don't support multipart with presigned URLs.

   * iterable containing two inner lists of three elements each, all in the original order.
   *
   * <p>Iterators returned by the returned iterable do not support the {@link Iterator#remove()}
   * method.
   *
   * @param iterable the iterable to return a partitioned view of
   * @param size the desired size of each partition

   * overkill for most Atomics because they are usually irregularly
   * scattered in memory and thus don't interfere much with each
   * other. But Atomic objects residing in arrays will tend to be
   * placed adjacent to each other, and so will most often share
   * cache lines (with a huge negative performance impact) without
   * this precaution.
   *

   * 1] < [1, 2] < [2]}.
   *
   * <p>Note that {@code Collections.reverseOrder(lexicographical(comparator))} is not equivalent to
   * {@code lexicographical(Collections.reverseOrder(comparator))} (consider how each would order
   * {@code [1]} and {@code [1, 1]}).
   */
  // Note: 90% of the time we don't add type parameters or wildcards that serve only to "tweak" the

 * already in the multimap has no effect. See the {@link Multimap} documentation for information
 * common to all multimaps.
 *
 * <p>The {@link #get}, {@link #removeAll}, and {@link #replaceValues} methods each return a {@link
 * Set} of values, while {@link #entries} returns a {@code Set} of map entries. Though the method
 * signature doesn't say so explicitly, the map returned by {@link #asMap} has {@code Set} values.
 *

 * already in the multimap has no effect. See the {@link Multimap} documentation for information
 * common to all multimaps.
 *
 * <p>The {@link #get}, {@link #removeAll}, and {@link #replaceValues} methods each return a {@link
 * Set} of values, while {@link #entries} returns a {@code Set} of map entries. Though the method
 * signature doesn't say so explicitly, the map returned by {@link #asMap} has {@code Set} values.
 *