que - ¿Cómo fuerzo a Maven a usar mi repositorio local en lugar de ir a repositorios remotos para recuperar artefactos?
maven tutorial español (7)
Estoy usando Maven 3.3.3 con Java 8 en Mac Yosemite. Tengo un proyecto de varios módulos.
<modules>
<module>first-module</module>
<module>my-module</module>
…
</modules>
Cuando construyo uno de mis módulos secundarios, por ejemplo, "my-module" desde arriba, usando "mvn clean install", la compilación intenta descargar los artefactos del módulo secundario desde un repositorio remoto que he definido en mi ~ / .m2 /settings.xml. La salida está por debajo
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building my-module 87.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml (788 B at 0.9 KB/sec)
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-20151104.200545-4.pom
¿Cómo fuerzo a Maven a verificar mi ~ / .m2 / repositorio local antes de intentar descargar desde los repositorios remotos? A continuación es donde tengo mis repositorios remotos definidos en mi archivo ~ / .m2 / settings.xml ...
<profile>
<id>releases</id>
<activation>
<property>
<name>!releases.off</name>
</property>
</activation>
<repositories>
<repository>
<id>releases</id>
<url>https://my.remoterepository.com/nexus/content/repositories/releases/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
</profile>
<profile>
<id>snapshots</id>
<activation>
<property>
<name>!snapshots.off</name>
</property>
</activation>
<repositories>
<repository>
<id>snapshots</id>
<url>https://my.remoterepository.com/nexus/content/repositories/snapshots/</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
</profile>
Editar: en respuesta a la respuesta que dice que la descarga se produce cuando el artefacto no está allí, a continuación se muestra la salida del terminal en la que pruebo que el archivo estaba allí en mi repositorio, pero Maven está tratando de descargarlo de todos modos ...
Daves-MacBook-Pro-2:my-module davea$ ls -al ~/.m2/repository/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-SNAPSHOT.jar
-rw-r--r-- 1 davea staff 10171 Nov 5 10:22 /Users/davea/.m2/repository/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-SNAPSHOT.jar
Daves-MacBook-Pro-2:my-module davea$ mvn clean install
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.mainco.subco:my-module:jar:87.0.0-SNAPSHOT
[WARNING] ''build.plugins.plugin.(groupId:artifactId)'' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-antrun-plugin @ org.mainco.subco:my-module:[unknown-version], /Users/davea/Documents/sb_workspace/my-module/pom.xml, line 678, column 12
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building my-module 87.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml (788 B at 0.8 KB/sec)
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-20151106.043202-8.pom
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first- module-87.0.0-20151106.043202-8.pom (3 KB at 21.9 KB/sec)
Downloading: http://download.java.net/maven/2/org/mainco/subco/subco/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/subco/87.0.0-SNAPSHOT/maven-metadata.xml
En mi caso, tuve un proyecto de varios módulos como tú. Tuve que cambiar el Id. De grupo de una de las bibliotecas externas de las que dependía mi proyecto, como se muestra a continuación.
De:
<dependencyManagement>
<dependency>
<groupId>org.thirdparty</groupId>
<artifactId>calculation-api</artifactId>
<version>2.0</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
<dependencyManagement>
A:
<dependencyManagement>
<dependency>
<groupId>org.thirdparty.module</groupId>
<artifactId>calculation-api</artifactId>
<version>2.0</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
<dependencyManagement>
Presta atención a la sección <groupId>. Resultó que me estaba olvidando de modificar la sección correspondiente de los submódulos que definen esta dependencia en sus archivos pom.
Me volvió muy loco porque el módulo estaba disponible localmente.
La dependencia tiene una versión de instantánea. Para las instantáneas, Maven verificará el repositorio local y si el artefacto encontrado en el repositorio local es demasiado viejo, intentará encontrar uno actualizado en los repositorios remotos. Eso es probablemente lo que estás viendo.
Tenga en cuenta que este comportamiento está controlado por la directiva
updatePolicy
en la configuración del repositorio (que es
daily
de forma predeterminada para los repositorios de instantáneas).
La opción -o no funcionó para mí porque el artefacto todavía está en desarrollo y aún no está cargado y Maven (3.5.x) todavía intenta descargarlo desde el repositorio remoto porque es la primera vez, de acuerdo con el error que recibo.
Sin embargo, esto me lo arregló: maven.apache.org/general.html#importing-jars
Después de esta instalación manual, tampoco es necesario usar la opción fuera de línea.
ACTUALIZAR
Acabo de reconstruir la dependencia y tuve que volver a importarla: la
mvn clean install
normal de
mvn clean install
no fue suficiente para mí
Maven siempre verifica primero su repositorio local, sin embargo, su dependencia debe estar instalada en su repositorio para que maven la encuentre.
Ejecute
mvn install
en su módulo de dependencia primero y luego
mvn install
su módulo dependiente.
Para
forzar
verdaderamente a Maven a usar
solo
su repositorio local, puede ejecutar con
mvn <goals> -o
.
El
-o
le dice a Maven que te permita trabajar "sin conexión", y permanecerá fuera de la red.
Siga los pasos a continuación:
1.Asegúrese de eliminar todo el contenido de la carpeta jar ubicada en su local, excepto el jar que desea conservar.
Por ejemplo, archivos como repositorios, .pom, .sha1, .lastUpdated, etc.
2.Ejecute el comando mvn clean install -o
Esto ayudará a usar archivos jar de repositorio local en lugar de conectarse a cualquier repositorio.
Use
mvn --help
y podrá ver la lista de opciones.
Hay una opción como
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
Entonces, use el comando
mvn install -nsu
puede forzar la compilación con el repositorio local.