Question: Jenkins is installing the most-recently built artifact to the local Maven repository, even when the job is executed with a goal of only `clean package`.

This caused an issue when someone accidentally committed an updated version of a shared library without incrementing the version number in the library's POM. Jenkins built the jar, installed it to the local Maven repository, and then (as configured) deployed the artifact to our shared Nexus repository. Nexus quite rightly refuses to accept the new artifact, as it already has a release with the given version number.

Some time later Jenkins builds a project that depends on that library, and uses the copy of the library from its *local* Maven repository rather than Nexus. Thus the project got built with the wrong version of the code.

It seems there are two possible solutions:

1. Stop Jenkins from erroneously installing the .jar to the local
repository
2. Prevent the local repository from being used when
building projects that depend on the library

Answer: 
It's the **install** goal that publishes to the local repository... So I've no answer for the first problem.

The second problem can be solved by isolating each build. Configure them to use their own local repositories so that mistakes in one don't affect others:

```
mvn -s settings.xml compile package

```

In the settings file declare unique path for the build job's local repository

```
<settings>
  <localRepository>/data/job1/repository</localRepository>
  ..

```

And it's probabily a good idea to periodically purge the local repositories, forcing clean builds.
There is a setting in the Jenkins job configuration to use a private repository. This way you can avoid artefacts from your Jenkins build finding their way into your main repository. You need to open the extended options for the Maven build to see the option.