Maven Clean Plugin, Maven Install Plugin, Maven Deploy Plugin

Maven drives builds through a lifecycle, and each phase in that lifecycle is carried out by specific plugin goals. Among the built-in plugins that ship with Maven, maven-clean-plugin, maven-install-plugin, and maven-deploy-plugin handle three essential steps: removing old build artifacts, installing them to the local repository, and publishing them to a remote repository. Understanding what each plugin does and how to configure it is fundamental to effective Maven-based engineering.

These plugins are bound to different lifecycle phases:

• maven-clean-plugin is bound to the clean phase of the clean lifecycle and removes files produced by previous builds.
• maven-install-plugin is bound to the install phase of the default lifecycle and copies artifacts into the local repository.
• maven-deploy-plugin is bound to the deploy phase of the default lifecycle and uploads artifacts to a remote repository.

Their scope expands step by step: clean affects only the project directory, install affects the local machine, and deploy shares artifacts with the entire team.
When you run mvn clean, Maven invokes the clean:clean goal. By default, this deletes the target directory at the project root, which contains compiled classes, packaged archives, and other build outputs. Because the plugin is straightforward, most teams use it without changes, but you can customize what gets removed.

For example, if a code generator writes temporary files into src/main/generated, you can add that directory to the cleanup set:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-clean-plugin</artifactId>
    <version>3.3.2</version>
    <configuration>
        <filesets>
            <fileset>
                <directory>src/main/generated</directory>
                <includes>
                    <include>**/*.java</include>
                </includes>
            </fileset>
        </filesets>
    </configuration>
</plugin>

The filesets element lets you define extra directories and Ant-style include patterns. If you want to keep the default target directory intact, set excludeDefaultDirectories to true.

maven-install-plugin: Installing to the Local Repository

Running mvn install triggers the install:install goal. The plugin takes the packaged artifact—JAR, WAR, EAR, POM, or another format—and copies it together with its POM into the local repository, which defaults to ~/.m2/repository. Once installed, other projects on the same machine can resolve the artifact by its Maven coordinates.

This plugin is especially useful in two situations:

• Multi-module development: If module A depends on module B, module B must be installed into the local repository before A can resolve the dependency during its own build.
• Local sharing: Independent projects on one workstation can reuse artifacts without publishing them to a shared server.

For third-party JARs that are not available in any public repository—such as a proprietary Oracle JDBC driver—you can install the file manually using install:install-file:

mvn install:install-file \
  -Dfile=ojdbc8.jar \
  -DgroupId=com.oracle.database.jdbc \
  -DartifactId=ojdbc8 \
  -Dversion=19.8.0.0 \
  -Dpackaging=jar

After the command finishes, you can declare the dependency in any POM using the same groupId, artifactId, and version.

maven-deploy-plugin: Deploying to Remote Repositories

The mvn deploy command runs the deploy:deploy goal, which uploads the artifact and its metadata to a remote repository such as Nexus or Artifactory. This makes the artifact available to teammates and CI/CD systems.

Deployment requires configuration in two places. First, declare the target repositories in the project POM under distributionManagement:

<distributionManagement>
    <repository>
        <id>release-repo</id>
        <url>https://nexus.example.com/repository/maven-releases/</url>
    </repository>
    <snapshotRepository>
        <id>snapshot-repo</id>
        <url>https://nexus.example.com/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

Second, provide credentials in ~/.m2/settings.xml that match the repository IDs:

<servers>
    <server>
        <id>release-repo</id>
        <username>deploy-user</username>
        <password>secret</password>
    </server>
</servers>

The id in the <server> element must match the repository ID exactly; otherwise authentication fails. Maven decides whether to upload to the release repository or the snapshot repository based on the project version: versions ending in -SNAPSHOT go to the snapshot repository, while stable versions go to the release repository.

Common Combinations and Practical Tips

In day-to-day development, these plugins are frequently combined:

• mvn clean install: cleans the project, rebuilds it, and installs the result to the local repository. This is the most common command in multi-module development.
• mvn clean deploy: cleans, builds, and publishes directly to the remote repository. It is typically used in the release stage of a CI/CD pipeline.

You can control behavior from the command line with several properties:

• -Dmaven.install.skip=true: skips installation while still producing the package.
• -Dmaven.deploy.skip=true: skips deployment, which is useful when a module should be built but not published.
• -DupdateReleaseInfo=true: updates release metadata in the repository when publishing a stable version.

Summary

maven-clean-plugin, maven-install-plugin, and maven-deploy-plugin correspond to the clean-install-deploy chain that moves a build artifact from a local workspace to team-wide availability. Knowing their default behavior, configuration options, and command-line shortcuts helps developers work confidently with multi-module projects and private repositories. In practice, combine these plugins with CI/CD tooling, standardize on clean install for local integration and clean deploy for releases, and manage repository credentials carefully to keep build artifacts secure and traceable.