private SnapshotHierarchy removeWatchedHierarchiesOverLimit(SnapshotHierarchy root, Predicate<File> isWatchedHierarchy, int maximumNumberOfWatchedHierarchies, Invalidator invalidator) {
        hierarchies.removeIf(hierarchy -> !isWatchedHierarchy.test(hierarchy));
        SnapshotHierarchy result = root;
        int toRemove = hierarchies.size() - maximumNumberOfWatchedHierarchies;
        if (toRemove > 0) {
            LOGGER.info(

import static org.gradle.internal.snapshot.impl.SerializedLambdaQueries.serializedLambdaFor;

/**
 * Identifies a type in a classloader hierarchy. The type is identified by its name,
 * the classloader hierarchy by its hash code.
 */
public abstract class ImplementationSnapshot implements ValueSnapshot {

    protected final String classIdentifier;

        ImmutableSet<String> hierarchy = LazyToRealisedModuleComponentResolveMetadataHelper.constructHierarchy(configuration, configurationDefinitions);
        return createConfiguration(metadata.getId(), configurationName, configuration.isTransitive(), configuration.isVisible(), hierarchy,

    /**
     * Should we generate a deep and wide hierarchy ("worst case" scenario) or only a wide hierarchy?
     * <p>
     *     With a wide hierarchy, each group of libraries depend only on each other. There's a limited depth (~7) and
     *     several projects.  This tries to replicate a project with many subgroups of interconnected components.
     * <p>

     *
     * <p>There are two cases where this might be true: Gradle was invoked from a directory where there is no build script and no settings script in the directory hierarchy,
     * or Gradle was invoked from a directory where there is a settings script in the directory hierarchy but the directory is not a project directory for any project defined
     * in that settings script.</p>
     */
    public boolean isBuildDefinitionMissing() {

            && dependencyScope != MavenScope.System;
    }

    private boolean include(MavenDependencyDescriptor dependency, Collection<String> hierarchy) {
        if (dependency.isOptional()) {
            return false;
        }
        return hierarchy.contains(dependency.getScope().getLowerName());
    }

    @Override
    public MutableMavenModuleResolveMetadata asMutable() {

    }

    def "task names must not contain forbidden characters"() {
        given:
        buildFile << "task 'this/is/a/hierarchy'"

        when:
        fails 'this/is/a/hierarchy'

        then:
        assertFailureContainsForbiddenCharacterMessage('task name',"this/is/a/hierarchy")
    }

    def "configuration names must not contain forbidden characters"() {
        given:

                collector.add(dependencyDescriptor);
            }
        });
    }

    /**
     * We write types hierarchy and metadata with dependencies as a separate file, since
     * type hierarchy is an input to {@link MergeInstrumentationAnalysisTransform}.
     */

    @Nullable
    File getDestinationDir();

    /**
     * Listener triggered when a spec is added to the hierarchy.
     */
    interface CopySpecListener {
        void childSpecAdded(CopySpecAddress path, CopySpecInternal spec);
    }

    /**
     * A visitor to traverse the spec hierarchy.
     */
    interface CopySpecVisitor {
        void visit(CopySpecAddress address, CopySpecInternal spec);
    }

//   - Names may contain at most one ':'. In the counter "foo:bar", we refer to
//     "foo" as the "chart name" and "bar" as the "bucket name".
//
//   - The '/' character should partition counter names into a hierarchy. The
//     root of this hierarchy should identify the logical entity that "owns"
//     the counter. This could be an application, such as "gopls" in the case
//     of "gopls/client:vscode", or a shared library, such as "crash" in the