@Inject
    private RepositorySystem repoSystem;

    @Inject
    private LegacySupport legacySupport;

    /** @deprecated we want to use the artifact method only, and ensure artifact.file is set correctly. */
    @Deprecated
    public void install(String basedir, String finalName, Artifact artifact, ArtifactRepository localRepository)

import org.apache.maven.artifact.repository.ArtifactRepository;
import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
import org.apache.maven.wagon.events.TransferListener;

/**
 */
// Just hide the one method we want behind the RepositorySystem interface.
@Deprecated
public interface ArtifactResolver {

    ArtifactResolutionResult resolve(ArtifactResolutionRequest request);

    // The rest is deprecated

create Log instances for this application. This is normally accomplished by calling the static getFactory() method. This method implements the following discovery algorithm to select the name of the LogFactory implementation class this application wants to use: Check for a system property named org.apache.commons.logging.LogFactory. Use the JDK 1.3 JAR Services Discovery mechanism (see http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html for more information) to look for a resource named META-INF...

            configuration). This is useful when you want to force the user to use common POM elements rather than
            plugin configurations, as in the case where you want to use the artifact's final name as a parameter. In
            this case, you want the user to modify {@code <build><finalName/></build>} rather

     * on the command line.
     */
    private List<MavenProject> projects;

    /**
     * The full set of projects before any potential constraining by --projects. Useful in the case where you want to
     * build a smaller set of projects but perform other operations in the context of your reactor.
     */
    private List<MavenProject> allProjects;

    private MavenProject topLevelProject;

 * This is only necessary for default components using @Typed that want to support overriding.
 *
 * As a non-default component this now gets a negative priority relative to other implementations
 * of the same interface. Since we want to allow overriding this doesn't matter in this case.
 * (if it did we could add @Priority of 0 to match the priority given to default components.)

 * only meant as a utility for developers that want to employ the model builder outside the Maven build system, Maven
 * plugins should always acquire model builder instances via dependency injection. Developers might want to subclass
 * this factory to provide custom implementations for some of the components used by the model builder, or use the

    <exportedPackage>jakarta.annotation.*</exportedPackage>

    <!--
      | 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

    filesystem.

    It is not possible to determine whether a file-based location will
    be available except on a case-by-case basis (or a root-url by
    root-url basis). We may want to move the offline sensitivity entirely to
    Maven-Artifact, below, so we can be smarter about testing filesystem-based
    repositories, etc.

  * If not otherwise specified, all other wagons are assumed to be

main channel of communication for contributors.  
There are some guidelines which will make applying PRs easier for us:
+ Create a topic branch from where you want to base your work (this is usually the master branch).
  Push your changes to a topic branch in your fork of the repository.
+ Make commits of logical units.