Algoritmo para resolver problemas "Maven no funciona para mí"

Question

Uno de los problemas más comunes y molestos que encuentro con Maven es el proceso de construcción que falla/pasa dependiendo de quién, cuándo y en qué máquina está ejecutando el proceso.

Más formalmente - en el mundo ideal Esperaría que el proceso de compilación sea repetible. Como programador, diría que espero que el proceso de compilación sea como el pure function del código fuente y los recursos como entrada de compilación y "un entorno". Esperaría que devuelva el mismo resultado en cualquier momento y en cualquier lugar que lo "evalúe" utilizando "entorno fijo" y espero (más bien deseo) que todos en el equipo tengan el mismo "entorno fijo".

En el mundo real o bien "un entorno" cambia con el tiempo o varía entre las máquinas de desarrollo, posiblemente porque incluye algunas dependencias que ni se espera ni se da cuenta.

Lo que estoy tratando de lograr haciendo esta pregunta es encontrar/definir un algoritmo/procedimiento o una lista de verificación para la resolución de problemas no repetibles en los procesos de compilación de Maven. Supongamos que tenemos dos máquinas separadas A y B con el mismo sistema operativo y que estamos construyendo exactamente la misma versión de nuestra aplicación en ellas, pero dan resultados diferentes (por ejemplo, una es exitosa y la otra falla). Dónde/cómo uno debe buscar las diferencias entre estos dos "entornos".

Estos son algunos pasos que suelo usar:

1. comparar los POM efectivas obtenidas a través de mvn help:effective-pom
2. comparar versiones ejecutables MVN + otras herramientas involucradas (por ejemplo, JDK)
3. comparar los valores de entorno (obtenidas bajo Windows de comandos mediante la línea de comandos set)
4. settings.xml comparar los archivos de los directorios home del usuario,
5. comp classpaths son generados utilizando mvn dependency:build-classpath
6. repositorio de borrado o incluso ambos repositorios

Cualquier idea qué más puede dar informaciones valiosas? Tal vez hay una mejor manera en la que simplemente me estoy perdiendo ...

Answer 1

He visto muchas versiones de Maven deslizarse en diferentes máquinas debido a las diferentes versiones de Maven o Java y errores o características asociadas. Incluso he visto construcciones fallar y transmitir la misma máquina cuando, por ejemplo, construido en la línea de comandos vs. construido en un IDE.

Si se invocan las herramientas de línea de comandos, puede encontrar que dependen de la plataforma o de la máquina. Lo he visto más notablemente en tareas de paquete que crean archivos .dmg en Mac o .msi en máquinas con Windows, y el paquete debe ejecutarse en estos sistemas operativos para crear archivos específicos.

La codificación de archivos tanto de recursos como de archivos fuente me ha causado problemas en el pasado. Comprobar que la propiedad project.build.sourceEncoding está configurada parece información útil. En lugar de contrario a la intuición, parece que se usa cuando se copian o filtran recursos, pero se ignora al tratar con los archivos fuente, IIRC.

Answer 2

un seguimiento de lo que haces y ser capaz de realizar un seguimiento de lo que los desarrolladores hacen:

1. crear una máquina de construcción (para las versiones de lanzamiento), la documentación de todos y cada pieza de software instalado, y la opción de todos y cada configuración elegida
2. Las máquinas de compilación privadas se deben configurar de la misma manera para garantizar la máxima probabilidad de una compilación trabajando
3. Cuando una compilación privada falla, enumere las configuraciones de software & y diferencielas de la configuración de publicación. Las diferencias son asumidos sin apoyo y deben ser corregidos para alcanzar la máxima verosimilitud de una construcción exitosa

Answer 3

Vamos a hacer tostadas estilo americano: a quemar, voy a raspar. --W. Edwards Deming.

En lugar de buscar un algoritmo para solucionar los problemas de no repetible construye, corregir la causa raíz, que sean repetibles siguiendo las buenas prácticas (Maven se basa en un 100% repetible si lo usa derecha):

• utilizar la misma versión de Maven en todas las máquinas de un determinado proyecto (distribuir una versión empaquetada)
• utilizar la misma versión del JDK (por lo menos la misma versión para un proyecto determinado)
• de bloqueo hacia abajo plugins cinco rsions en sus poms para construir reproducibilidad
• hacer cumplir las reglas anteriores usando el Maven Enforcer Plugin
• utilizar un diccionario de la empresa (y sólo el diccionario de la empresa)
• toma de evitar construye no portátil añadiendo cosas no específicos de usuario en ~/.m2/settings.xml
• poner todo bajo control de versiones (POM eficaz debe ser idéntico en todos los equipos)
• carrera limpia se basa en una máquina de construcción (la referencia)

He usado Maven en organizaciones con cientos de desarrolladores sin experimentar los problemas que describes. En realidad, y lamento decir que los problemas que enfrenta no son culpa de Maven, solo son el resultado de malas prácticas de desarrollo (no quiero ser grosero, pero eso es cierto).

Answer 4

No es realmente una respuesta per se, pero eliminamos todo el repositorio local en la máquina de compilación todas las semanas.

La máquina de compilación también está restringida a un pequeño conjunto de repos locales y proxy que los desarrolladores no pueden editar.

Al principio teníamos muchas compilaciones que simplemente dejaban de funcionar después de eliminar el repositorio. Ahora es un problema mensual. Su tendencia a un problema de cada dos meses.

Esto ha promovido una serie de buenas prácticas para bloquear números de versión, versiones de plugins, usar perfiles para construcciones locales, usar excluye cuando sea necesario y agregar jar de terceros a los lugares correctos.