When the deploy target is run, the Clover lifecycle doesn't deploy its artifacts. There is a JIRA issue CLMVN-9 open for this limitation.

As a work around, you can use the build-helper-maven-plugin as follows:

• The general idea is to attach the instrumented jar (the primary artifact of the clover-plugin forked lifecycle) as a secondary artifact to the original lifecycle by means of the build-helper-maven-plugin. A normal 'mvn deploy' (which targets the original lifecycle) will then lead to the desired deployment of the instrumented jar.
• The complicated thing in the attachment of the forked lifecycle's primary artifact (the instrumented jar, that is) to the original lifecycle is, that the forked lifecycle will inherit the whole original lifecycle's configuration, including the introduced attachment. Thus, the forked lifecycle will have the same artifact (its primary artifact) both as primary and as a secondary artifact. Maven will enforce distinct names for the two, leading to necessary classifier substitution in the build-helper configuration:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>build-helper-maven-plugin</artifactId>
    <executions>
      <execution>
        <id>attach-instrumented-jar</id>
        <phase>verify</phase>
        <goals>
          <goal>attach-artifact</goal>
        </goals>
        <configuration>
          <artifacts>
            <artifact>
              <file>
                ${basedir}/target/clover/${project.artifactId}-${project.version}-clover.jar
              </file>
              <type>jar</type>
              <classifier>clovered</classifier>
            </artifact>
          </artifacts>
        </configuration>
      </execution>
  </executions>
</plugin>

A subsequent 'mvn deploy' will lead to a deployment of the instrumented jar, the 'Clovered' version as a secondary artifact along with the non-instrumented (original lifecycle's) primary artifact.