/**
 * A test which demonstrates maven's recursive inheritance where
 * we are testing to make sure that elements stated in a model are
 * not clobbered by the same elements elsewhere in the lineage.
 *
 */
@Deprecated
class ProjectInheritanceTest extends AbstractProjectInheritanceTestCase {
    // ----------------------------------------------------------------------
    //

    }

    @Override
    public OneSizeTestContainerGenerator<Map<K, V>, Entry<K, V>> getInnerGenerator() {
      return mapGenerator;
    }
  }

  // TODO(cpovirk): could something like this be used elsewhere, e.g., ReserializedListGenerator?
  static class ForwardingTestMapGenerator<K extends @Nullable Object, V extends @Nullable Object>
      implements TestMapGenerator<K, V> {
    TestMapGenerator<K, V> delegate;

        VersionRange mergedRange = range1.restrict(range2);
        // TODO current policy is to retain the original version - is this correct, do we need strategies or is that
        // handled elsewhere?
        //        assertEquals( "1.1", mergedRange.getRecommendedVersion().toString(), CHECK_VERSION_RECOMMENDATION );
        assertEquals("1.0", mergedRange.getRecommendedVersion().toString(), CHECK_VERSION_RECOMMENDATION);

    try {
      if (future.isCancelled()) {
        // Clear futures prior to cancelling children. This sets our own state but lets
        // the input futures keep running, as some of them may be used elsewhere.
        futures = null;
        cancel(false);
      } else {
        collectValueFromNonCancelledFuture(index, future);
      }
    } finally {
      /*

// When a policyName is given to this function, the policy association is
// created and stored in the IAM store. Thus, it should NOT be given for the
// role-arn case (because the role-to-policy mapping is separately stored
// elsewhere), the AssumeRole case (because the parent user is real and their
// policy is associated via policy-set API) and the AssumeRoleWithLDAP case
// (because the policy association is made via policy-set API).