/**
 *
 *
 *
 */
@Deprecated
public class MetadataResolutionRequest {
    private MavenArtifactMetadata mad;

    private String scope;

    // Needs to go away
    private Set<Artifact> artifactDependencies;

    private ArtifactRepository localRepository;

    private List<ArtifactRepository> remoteRepositories;

            // -1
            //  or QUALIFIERS.size and then resort to lexical ordering. Most comparisons are decided by the first
            // character,
            // so this is still fast. If more characters are needed then it requires a lexical sort anyway.
            return i == -1 ? (QUALIFIERS.size() + "-" + qualifier) : String.valueOf(i);
        }

        @Override
        public int compareTo(Item item) {

    <!--
      | We may potentially want to export these, but right now I'm not sure that anything Guice specific needs
      | to be made available to plugin authors. If we find people are getting fancy and want to take advantage of
      | Guice specifics we can expose that later. Really some testing needs to be done to see full hiding
      | of Guice has any impact on what we may categorize as a standard JSR-330 based Tesla/Maven plugin.

     *
     * <p>This map may contain null values if the constructor was invoked with {@code resolve}
     * parameter set to false. This is more efficient when only the module existence needs to
     * be tested, and module descriptors are not needed.</p>
     *
     * @see #getModuleNames()
     */
    private final Map<Path, String> descriptors;

    /**

    //      mojo descriptor which comes back. All the free form parsing needs to be done somewhere else, this is
    //      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

 various properties files. What needs to be done is to encapsulate all of this in the POM.

 Typically users parameterize the use of plugins, or have custom values like ${user.name}
 for use in elements like the <developerConnection/>. It would be idea if we
 could encapsulate everything we need about the project in the POM including
 plugin parameters and anything else.

 * supplies lazily constructed instance, and on each subsequent call same instance. Hence, this instance should be
 * thrown away immediately once repository system was created and there is no need for more instances. If new
 * repository system instance needed, new instance of this class must be created. For proper shut down of returned
 * repository system instance(s) use {@link RepositorySystem#shutdown()} method on supplied instance(s).
 * <p>

  DefaultExpressionEvaluator used within. See the above discussion for more
  on why this evaluator is bad. We need to provide either an alternative
  implementation under a different roleHint, or else replace the
  BasicComponentConfigurator.

* Other

  We may need to define a new lifecycle/phase to contextualize a mojo right
  before it's used, and reset it's state afterward. Up to now, the approach

                MavenProject currentProject = session.getCurrentProject();
                try {
                    BuilderCommon.attachToThread(project); // Not totally sure if this is needed for anything
                    session.setCurrentProject(project);
                    projectBuilds.add(new ProjectSegment(project, taskSegment, session));
                } finally {

 *
 */
@Deprecated
public class ArtifactResolutionRequest implements RepositoryRequest {
    private static final String LS = System.lineSeparator();

    private Artifact artifact;

    // Needs to go away
    // These are really overrides now, projects defining dependencies for a plugin that override what is
    // specified in the plugin itself.
    private Set<Artifact> artifactDependencies;