2010-01-26 10 views
10

En mi proyecto, hay una serie de dependencias que se incluyen transitoriamente de otras dependencias que no tienen archivos pom.xml disponibles en ninguno de nuestros repositorios corporativos. Estas son bibliotecas internas solo de jar compatibles con varios equipos que se han subido a los repositorios para conveniencia de equipos que no son de Maven, sin embargo, desafortunadamente, estos repositorios no son míos para jugar.¿Cómo evito que Maven 2.x intente recuperar archivos pom.xml inexistentes para las dependencias de cada compilación?

Para estas dependencias, Maven insiste en intentar recuperar los poms de cada una de las listas de mi repositorio cada vez que ejecuto una compilación, o mvn dependency:list. Esto significa que maven intenta recuperar 8x archivos pom de 7 diferentes ubicaciones de repositorio, y dado que esto se realiza a través de la WAN corporativa global; es realmente lento

p. Ej. para una determinada dependencia

C:\Working\dev\workspace\project>mvn dependency:list 
[INFO] Scanning for projects... 
[INFO] Searching repository for plugin with prefix: 'dependency'. 
[INFO] ------------------------------------------------------------------------ 
[INFO] Building project 
[INFO] task-segment: [dependency:list] 
[INFO] ------------------------------------------------------------------------ 
[WARNING] Unable to get resource 'aGroupId:anArtifactId:pom:4.0.14i' from repository inhouse (http://someRepo1/proximity/repository/inhouse): While configuring wagon for 'inhouse': Unable to apply wagon configuration. 
Downloading: http://someRepo1/proximity/repository/extFree/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom 
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository extFree (http://someRepo1/proximity/repository/extFree) 
Downloading: http://someRepo1/proximity/repository/externalNonFree/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom 
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository extNonFree (http://someRepo1/proximity/repository/externalNonFree) 
Downloading: http://someRepo2/efs/dist/maven/maven2-repository/incr/common/lib/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom 
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository efsRepo (http://someRepo2/efs/dist/maven/maven2-repository/incr/common/lib) 
Downloading: http://someRepo2/efs/dist/btijava/maven2-repository/incr/common/lib/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom 
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository efsBTI (http://someRepo2/efs/dist/btijava/maven2-repository/incr/common/lib) 
Downloading: http://someRepo3/maven/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom 
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository internal.repo (http://someRepo3/maven) 
Downloading: http://repo1.maven.org/maven2/aGroupId/anArtifactId/4.0.14i/anArtifactId-4.0.14i.pom 
[INFO] Unable to find resource 'aGroupId:anArtifactId:pom:4.0.14i' in repository central (http://repo1.maven.org/maven2)` 
... 
etc 
... 
[INFO] [dependency:list {execution: default-cli}] 
[INFO] 
[INFO] The following files have been resolved: 
... etc 
[INFO] ------------------------------------------------------------------------ 
[INFO] BUILD SUCCESSFUL 
[INFO] ------------------------------------------------------------------------ 
[INFO] Total time: 20 seconds 
[INFO] Finished at: Tue Jan 26 15:01:48 CST 2010 
[INFO] Final Memory: 31M/74M 
[INFO] ------------------------------------------------------------------------ 

Por otro lado, para los POM que son sólo válidos (modelVersion más, o XML corruptos/no válido, por ejemplo) sólo chequea mi repo locales, se queja de que es inválido y luego continúa. Lo cual está bien; al menos eso no intenta de nuevo a través de la WAN.

¿Hay alguna manera (configuración, anulación, cambio de configuración del repositorio) puedo evitar que el plugin de dependencias/artefactos de Maven intente repetidamente localizar POM faltantes, si ya tiene el archivo jar en el repositorio local?

Especificaciones: Maven 2.2.1 (por defecto superPOM definiciones plugin) JDK 1.6.0_18

Respuesta

9

La respuesta de Pascal es correcta para dos soluciones locales de compilación. Sin embargo, su mejor opción es solicitar a los propietarios de estos proyectos que creen POM para los artefactos. Ellos no necesitan ser complejas, el simple alternativa que Maven está utilizando internamente funcionará:

<project> 
    <modelVersion>4.0.0</modelVersion> 
    <groupId>aGroupId</groupId> 
    <artifactId>aArtifactId</artifactId> 
    <version>4.0.14i</version> 
</project> 
+0

Tenía la esperanza de evitar tener que caminar penosamente por la corporación encontrando a los dueños de todos los artefactos. Pero si realmente no hay forma de alterar esta parte del comportamiento de Maven, creo que tendré que hacer eso. Me parece extraño que Maven acepte un POM local repo corrupto/incompatible sin intentar recuperarlo de nuevo, pero uno inexistente lo seguirá intentando para siempre, incluso si tuvo éxito en recuperar un jar. – Chad

+0

Utilicé este trabajo y me funcionó muy bien. Había intentado establecer tiempos de espera en los diferentes repositorios sin éxito. – jtruelove

+2

¡Guau, es Brett Porter del equipo de Maven! –

4

la descarga de un POM es realmente un concepto central en Maven para apoyar dependencias transitivas (en realidad, una dependencia no es sólo una JAR, vea 3.5.5. Maven's Dependency Management para obtener detalles sobre eso) así que no sé si puede evitarlo.

Por supuesto, lo correcto sería corregir la causa raíz del problema. Pero si no puede, quizás pueda ejecutar su compilación en modo fuera de línea (usando la opción -o). O tal vez podría simplemente "instalar" los artefactos en su repositorio local usando install:install-file e indicarle al plugin que genere un pom para ellos usando el parámetro opcional generatePom (pero esto obviamente no se "escala" realmente bien).

+0

Gracias Pascal. Sí, entiendo que es un concepto central, pero desafortunadamente, como suele ser el caso en corporaciones con silos (intencionalmente) no tengo control sobre su repositorio Maven, pero nuevamente necesito poder recuperar sus artefactos de construcción.Para algunas dependencias, ni siquiera está claro quién es responsable de ellas, ¡así que es difícil saber a quién preguntar! Si otros expertos han llegado a la misma conclusión de que no hay forma de hacerlo, está bien, al menos sé que no estoy loco. Y sí, los hacks locales no son realmente óptimos para los motivos de escalabilidad a los que se puede llegar. – Chad

2

Establecer un nexo repositorio (o similar) y cargar los artefactos allí. Nexus creará automáticamente poms básicos para los artefactos que cargue.

+0

Esta es la solución que acabo de utilizar cuando se trata de sonatype-flex-group que no tiene poms en su proyecto de halo. Crea un pom simple que luego implementé en el repositorio de "versiones de terceros" en Nexus. Las compilaciones continúan bastante felices, y en el repositorio agregado "público" nunca se sabe que el pom y el swc provienen de diferentes repos internos/proxy. –

-1
  • descarga de repo local de
  • configuración nexo y cargar
  • trabajar sin conexión

tal vez la mejor idea es deshacerse del experto hasta el final, es de terror!

Cuestiones relacionadas