maven ne peut pas trouver mes artefacts locaux
Je n'arrive pas à exécuter mvn -o package car il se plaint
Le système de référentiel est hors ligne mais l'artefact com.liferay.portal: ponts-util: jar: 6.1.20 n'est pas disponible dans le référentiel local.
Mais j'ai vérifié mon référentiel local et cet artefact existe bel et bien là-bas. J'ai également essayé la solution consistant à définir updatePolicy de manière à ne jamais figurer dans le fichier settings.xml mais cela n'a pas fonctionné.
Avant Maven 3.0.x, Maven ne suivait pas l'origine des fichiers dans le référentiel local.
Cela pourrait entraîner des problèmes de construction, en particulier si vous construisez quelque chose qui répertorie le référentiel Java.net2 (maintenant mort) très encombré ... Non seulement le référentiel a modifié les artefacts publiés (pratique extrêmement mauvaise et perverse), mais il a également publié des artefacts à l'adresse suivante: les mêmes coordonnées que les artefacts sur le centre mais avec un contenu différent (incroyablement pervers)
Donc, vous pourriez avoir le travail de construction (parce que vous aviez commons-io: commons-io: 2.0 depuis le centre) effacer votre référentiel local et la construction échouait (car vous obtenez maintenant commons-io: commons-io: 2.0 depuis Java.net2 qui était un artefact complètement différent avec des dépendances différentes dans le pom) ou vice versa.
La situation ci-dessus est l'un des facteurs permettant d'utiliser un gestionnaire de référentiels maven, car cela vous permet de contrôler le sous-ensemble d'un référentiel que vous exposez en aval et l'ordre dans lequel les artefacts sont résolus à partir de plusieurs référentiels (généralement appelés règles de routage).
Quoi qu'il en soit, lorsque maven est passé à Aether en tant que couche d'accès au référentiel, il a été décidé de commencer à rechercher l'origine des artefacts.
Ainsi, avec Maven 3.0.x, lorsqu'un artefact est téléchargé à partir d'un référentiel, maven laisse un fichier _maven.repositories pour enregistrer l'endroit à partir duquel le fichier a été résolu. Si vous construisez un projet et que la liste effective des référentiels n'inclut pas l'emplacement à partir duquel l'artefact a été résolu, Maven décide alors que c'est comme si l'artefact n'était pas dans le cache et tentera de résoudre à nouveau l'artefact. ..
Il y a cependant un certain nombre de bogues dans 3.0.x ... Le plus important étant de savoir comment offline est traité ... À savoir: en mode hors connexion, maven 3.0.x pense qu'il n'y a pas de référentiels, donc trouvera toujours une incompatibilité avec le fichier _maven.repositories !!!
La solution de contournement pour Maven 3.0.x consiste à supprimer ces fichiers de votre cache local, par exemple:
$ find ~/.m2/repository -name _maven.repositories -exec rm -v {} \;
L'effet secondaire est que vous perdez les protections que Maven 3.0.x tente de fournir.
La bonne nouvelle est que Maven 3.1 disposera de la solution nécessaire (si nous pouvons unir nos efforts et obtenir un communiqué de presse).
Avec Maven 3.1 en mode hors connexion, le fichier _maven.repositories est (semi-) ignoré. Il existe également une option permettant d'ignorer ce fichier pour les versions en ligne (mode hérité).
En ce moment (1er juin 2013), la 4ème tentative de création d'un communiqué conforme aux exigences légales et aux tests est en cours ... Donc, en supposant que la 4ème fois ait de la chance, je espère voir 3.1 .0-alpha-1 publié dans 3-4 jours ... Mais cela pourrait être plus long étant donné que nous voulons donner suffisamment de temps aux modifications de la version 3.1 pour que les builds d'utilisation ne se cassent pas (il y a eu un changement dans API exposée (accidentellement - l'API est nécessaire pour le site et le plugin de dépendance) dont les auteurs de plug-in ont dépendu (même s'ils n'auraient pas dû le faire), donc il y a un potentiel, même si nous pensons que toutes les bases sont couvertes)
J'espère que cela répond à votre question (et peut-être un peu plus que vous ne saviez pas que vous aviez ;-))
J'ai également dû supprimer _remote.repositories de la même manière que les _maven.repositories décrits ci-dessus. J'utilise Maven 3.1.1
find ~/.m2/repository -name _remote.repositories -exec rm -v {} \;
J'ai eu ce problème dans Ubuntu Linux lorsque j'ai installé des artefacts locaux via un script Shell. La solution consistait à supprimer les artefacts locaux et à les réinstaller "manuellement" en appelant mvn install:install-file via un terminal.
J'avais ce problème quand j'utilisais Apache-maven-3.0.4, le problème a disparu dès que je passe à Apache-maven-3.3.1.