})

        where:
        name          | prefix
        "bundles"     | "bundles"
        "versions"    | "versions"
        "plugins"     | "plugins"
        "bundles-my"  | "bundles"
        "versions_my" | "versions"
        "plugins.my"  | "plugins"
    }

    @VersionCatalogProblemTestFor(
        VersionCatalogProblemId.RESERVED_ALIAS_NAME
    )
    def "allows using #name as a dependency alias"() {

    private static final String BUNDLES_KEY = "bundles";
    private static final String VERSIONS_KEY = "versions";
    private static final String PLUGINS_KEY = "plugins";
    private static final Set<String> TOP_LEVEL_ELEMENTS = ImmutableSet.of(
        METADATA_KEY,
        LIBRARIES_KEY,
        BUNDLES_KEY,
        VERSIONS_KEY,
        PLUGINS_KEY
    );
    private static final Set<String> PLUGIN_COORDINATES = ImmutableSet.of(

In the example above, `A` would have to say it _strictly depends on 1.1_.

For this reason, a good practice is that if you use _strict versions_, you should express them in terms of ranges and a preferred version within this range.
For example, `B` might say, instead of `strictly 1.0`, that it _strictly depends_ on the `[1.0, 2.0[` range, but _prefers_ `1.0`.

### Changelog

#### 1.1

- Adds support to _endorse strict versions_ defined in another module: `{ "group": "some.group", "module": "other-lib", "version": { "requires": "3.4" }, "endorseStrictVersions": "true"`
- Adds `thirdPartyCompatibility` features for better compatibility with maven and ivy metadata

Here, we _manipulate the requested versions_ in order to select a different version when we find a rejected one.
In other words, this is a _solution_ to rejected versions, while rich version constraints allow declaring the _intent_ (you should not use this version).
====