Normalement, Jenkins utilise le repository Maven local que Maven détermine lui-même — le process exact ne semble pas documenté mais ce répertoire est généralement `~/.m2/repository`. Il peut être modifié par le paramêtre <localRepository> dans le fichier `~/.m2/settings.xml` (voir la référence pour plus de détails.)

Cela signifie que, normalement, tous les jobs qui sont exécutés sur le même noeud (même machine) partagent un repository Maven unique. L'avantage, c'est que vous économisez de l'espace disque. Par contre, il peut aussi arriver que ces builds interfèrent les uns avec les autres. Par exemple, vous pouvez finir par avoir des builds qui s'achèvent avec succès incorrectement, simplement parce que toutes les dépendances sont déjà dans votre repository local, alors que les repositories spécifiés dans le POM ne les contiennent pas.

Il semble aussi y avoir des problèmes quand des process Maven concurrents tendent d'accéder au même repository local.

Quand cette option est sélectionnée, Jenkins demandera à Maven d'utiliser `$WORKSPACE/.repository` comme répertoire local Maven. Du coup, chaque job aura son propre repository Maven parfaitement isolé. Cela règle les problèmes cités ci-dessus, en échange de plus d'espace disque.

Si vous utilisez cette option, pensez à mettre en place un gestionnaire d'artefacts Maven. Ainsi, vous ne serez pas forcés d'accéder aux repositories Maven distants trop fréquemment.

Si vous préférez activer ce mode pour tous les jobs Maven exécutés par Jenkins, référez-vous à la technique décrite ici.