Set<Binding<Q>> res = getBindings(key);
                if (res != null && !res.isEmpty()) {
                    List<Binding<Q>> bindingList = new ArrayList<>(res);
                    Comparator<Binding<Q>> comparing = Comparator.comparing(Binding::getPriority);
                    bindingList.sort(comparing.reversed());
                    Binding<Q> binding = bindingList.get(0);

    public Set<Plugin> getPluginsBoundByDefaultToAllLifecycles(String packaging) {
        Set<Plugin> plugins;

        // NOTE: The upper-case packaging name is intentional, that's a special hinting mode used for certain tests
        if ("JAR".equals(packaging)) {
            plugins = new LinkedHashSet<>();

            plugins.add(newPlugin("maven-compiler-plugin", "compile", "testCompile"));

 ---
 Hervé Boutemy
 ---
 2013-08-02
 ---

Plugins Bindings for <<<default>>> Lifecycle Reference

  The {{{./lifecycles.html}<<<default>>> lifecycle}} is defined without any plugin binding; plugins bindings are defined separately
  in {{{./apidocs/org/apache/maven/lifecycle/providers/packaging/package-summary.html}<<<org.apache.maven.lifecycle.providers.packaging>>>}} package
  because they are specific for each packaging:

%{toc|fromDepth=2}

* <<<default>>> Lifecycle

  <<<default>>> lifecycle is defined only with phases, <<without>> any associated plugin binding:
  plugins bindings for this lifecycle are {{{./default-bindings.html}defined separately for each packaging}}:

        <field xdoc.separator="blank" xml.insertParentFieldsUpTo="reporting">
          <name>profiles</name>
          <version>4.0.0+</version>
          <description>A listing of project-local build profiles which will modify the build process
            when activated.</description>
          <association>
            <type>Profile</type>
            <multiplicity>*</multiplicity>

  mode.

** Maven-Core

  We'll examine the different parts of maven-core on a case-by-case
  basis, below:

*** DefaultLifecycleExecutor

  When binding goals to the project's configured lifecycle, each mojo
  descriptor should declare whether it requires online/offline status.
  This value should be a java.lang.Boolean, so it can implement 3VL

    //      really the function of the CLI, and then the pre-processing of that output still needs to be fed into
    //      a hinting process which helps flesh out the full specification of the plugin. The plugin manager should
    //      only deal in concrete terms -- all version finding mumbo jumbo is a customization to base functionality
    //      the plugin manager provides.

    @Test

 * the same injector is immediately matched to this explicit binding, which means extensions
 * cannot override this binding. This is because the lookup is always short-circuited in this
 * specific situation (plain @Inject request, and plain explicit binding for the same type.)
 *
 * The simplest solution is to use a custom @Named here so it isn't bound under the plain key.
 * This is only necessary for default components using @Typed that want to support overriding.

    public Set<Plugin> getPluginsBoundByDefaultToAllLifecycles(String packaging) {
        Set<Plugin> plugins;

        // NOTE: The upper-case packaging name is intentional, that's a special hinting mode used for certain tests
        if ("JAR".equals(packaging)) {
            plugins = new LinkedHashSet<>();

            plugins.add(newPlugin("maven-compiler-plugin", "compile", "testCompile"));

    public Set<Plugin> getPluginsBoundByDefaultToAllLifecycles(String packaging) {
        Set<Plugin> plugins;

        // NOTE: The upper-case packaging name is intentional, that's a special hinting mode used for certain tests
        if ("JAR".equals(packaging)) {
            plugins = new LinkedHashSet<>();

            plugins.add(newPlugin("maven-compiler-plugin", "compile", "testCompile"));