Maven 3 no actualiza la dependencia de instantáneas desde el repository local

Estoy tratando de usar una biblioteca externa dentro de mi proyecto de Maven. Ya que quiero que el proyecto se desarrolle de manera mvn install en cualquier máquina, no quiero usar la solución de mvn install . Por lo tanto, he definido el repository local en mi pom.xml:

   com.test fooLib 1.0-SNAPSHOT  ....  in-project  always true  In Project Repo file://${project.basedir}/libRepo  

El problema es cuando sustituyo el libRepo jar en libRepo (sin actualizar el número de versión, ya que es solo otra instantánea) que no se utiliza este .m2 jar actualizado (en su lugar se usa la versión .m2 directorio .m2 ) incluso para mvn -U clean install Cómo hacer ¿Maven para actualizar este flask?

EDITAR : De acuerdo con ¿Qué es exactamente una instantánea de Maven y por qué la necesitamos? maven intentará encontrar nunca la versión de la dependencia SNAPSHOT, “incluso si una versión de esta biblioteca se encuentra en el repository local”. ¿Qué está mal con mi configuración?

SOLUCIÓN SUCIA : basada en la respuesta del ensamblaje de Maven 2 con dependencias: jar bajo el scope “sistema” no incluido. Parece que la extensión de mi solución original funciona:

   org.apache.maven.plugins maven-install-plugin   hack-binary validate  ${repo.path.to.jar} default com.test fooLib 1.0-SNAPSHOT jar true   install-file     

Como se mencionó en el comentario a esa solución, no funciona solo, por lo tanto, funciona en combinación con el repository in-project (que funciona cuando la dependencia no está disponible en el repository local .m2 ) y esta segunda parte actualiza .m2 durante cada comstackción.

Sin embargo, todavía no me queda claro por qué el mecanismo “SNAPSHOT” no funciona (es decir, la solución actual no funcionaría también sin SNAPSHOT, ya que el repository .m2 local se actualiza explícitamente cada vez). ¿Hay alguna forma más limpia?

SOLUCIÓN (basada en la respuesta y discusión de Aaron): El problema fue que intenté instalar el archivo en libRepo usando install-file . La solución real es que si la biblioteca se actualiza, use

 mvn deploy:deploy-file -Dfile=fooLib.jar -DgroupId=com.test \ -DartifactId=fooLib -Dversion=1.0-SNAPSHOT -Dpackaging=jar \ -Durl=file://..\libRepo -DrepositoryId=in-project 

Para desplegarlo a repo. Después de la implementación adecuada, Maven maneja correctamente SNAPSHOTs.

Si usa un repository para esto, Maven copiará el JAR una vez en su repository local (generalmente en $HOME/.m2/repository/ ). A menos que el número de la versión cambie, Maven no considerará que este archivo haya cambiado y no lo copiará. Tenga en cuenta que el número de versión es lo único que Maven mira; no importa las sums de comprobación o el tamaño de los archivos o las fechas.

Por cierto, a las instantáneas se les asigna un número de versión internamente solo para este propósito: para que Maven pueda notar internamente que una instantánea se ha actualizado.

Sugiero utilizar una dependencia del sistema en su lugar. De esa manera, el JAR real se agregará a la ruta de clase (sin ninguna copia o material). Tampoco necesita replicar una estructura de recompra para este enfoque y comunicará claramente su intención.

[EDITAR] Entiendo que Maven maneja las dependencias con el system scope de manera diferente. No estoy seguro de si esto tiene sentido o no (si usa la dependencia para comstackr, ¿seguramente puede usarlo para ejecutar?)

Como yo lo veo, tienes estas opciones:

  1. Instale la dependencia en su libRepo usando deploy: deploy-file en lugar de copiarlo usted mismo. Eso debería actualizar los metadatos de tal manera que Maven los vuelva a copiar cuando ejecute mvn install nuevamente en el proyecto real.

    Tenga en cuenta que el file:install no funciona. El complemento de archivo se utiliza para acceder al repository local, pero debe utilizar el complemento de implementación que sabe cómo actualizar un repository compartido / servidor.

  2. Instale la dependencia en su repository local; Sugiero usar un script para esto que pueda incluir en su proyecto. De esa manera, evitará todos los problemas y será fácil configurarlo en una nueva máquina.

  3. Cambie el número de versión de la dependencia, pero eso es tedioso y es posible que tenga problemas cuando cambie el número de versión real de la dependencia.

  4. Configure un servidor de repository local para su empresa y despliegue la dependencia a él. Eso tomará algunas horas, pero a) obtendrá un caché local de todas sus dependencias, lo que hará que sus construcciones iniciales sean más rápidas yb) hará que la configuración para desarrolladores adicionales sea mucho más rápida.

Maven nunca leerá el flask presente dentro de ninguna carpeta de la biblioteca. Primero debes entender cómo funciona el experto. El único lugar donde Maven busca jar es el localRepository (.m2) , si está ausente, busca el otro repository, mencionado en su POM.xml

El respondedor anterior (y un comentarista) señaló que Maven busca dentro del repository del proyecto local solo una vez, y en las comstackciones subsiguientes obtiene el contenedor almacenado en caché del repository .m2.

Acabo de encontrar una solución alternativa para la necesidad de incrementar el número de versión (por ejemplo, en pequeños cambios de una biblioteca de desarrollo):

Primero reinstale el jar en su repository de proyectos local:

 mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -DgroupId=com.johndoe.dev -DartifactId=Helpers -Dversion=0.1 -Dfile=C:/path/to/helpers.jar 

(Donde -Dfile podría apuntar a un proyecto externo que produce el helpers.jar)

Luego elimine solo este artefacto específico en el repository .m2:

 mvn dependency:purge-local-repository -DmanualInclude=com.johndoe.dev:Helpers:0.1 

(Con com.johndoe.dev como GroupId, Helpers como ArtifactId y la misma versión instalada en el paso anterior)

Al ejecutar el último paso, Maven reconstruye el artefacto dentro de .m2 utilizando su archivo jar local de repository de proyectos.

Variante alternativa y quizá sucia: simplemente copie helpers.jar en C: \ Users \ johndoe \ .m2 \ repository \ com \ johndoe \ dev \ Helpers \ 0.1 \ Helpers-0.1.jar (no sé sobre Linux como no lo tengo ‘ t utiliza mave allí).