maven 2 - smartgsm - ¿Dónde es el mejor lugar para especificar repositorios de maven, pom.xml o settings.xml?
zte maven 2 root (2)
¿Dónde es el mejor lugar para especificar los repositorios necesarios para proyectos de maven, pom.xml o settings.xml? ¿Cuáles son los pros y los contras de cada ubicación? ¿Qué es la mejor práctica?
Personalmente, definiría los repositorios requeridos por un proyecto en particular en el proyecto pom.xml porque mantiene la compilación portátil. El archivo settings.xml debería usarse para cosas específicas del usuario o secretas solo en mi opinión. No realmente, pedirle al usuario que agregue ubicaciones de repositorio, incluso si esto está bien documentado, de alguna manera anula una de las características de Maven (manejo de dependencia transparente) y no me gusta esta idea.
El único caso de uso "bueno" que se me ocurre al usar settings.xml para tratar con los repositorios es cuando tienes un repositorio corporativo y quieres que Maven use este repositorio en lugar de los públicos. Por ejemplo, para evitar conexiones a cualquier repositorio público, declararía el repositorio corporativo como un espejo de todos ellos:
<settings>
...
<mirrors>
<mirror>
<id>proxy-of-entire-earth</id>
<mirrorOf>*</mirrorOf>
<name>Maven Repository Manager running on repo.mycompany.com</name>
<url>http://repo.mycompany.com/proxy</url>
</mirror>
</mirrors>
...
</settings>
¿Dónde es el mejor lugar para especificar los repositorios necesarios para proyectos de maven, pom.xml o settings.xml ? ¿Cuáles son los pros y los contras de cada ubicación? ¿Qué es la mejor práctica?
Me parece que la definición de los repositorios en el POM es mejor por varias razones:
- Reproducibilidad: los artefactos dependientes provienen de una ubicación conocida que se declara explícitamente en el POM. También hay menos oportunidades para que los repositorios mal configurados de un usuario causen problemas.
- Portabilidad: este POM se construirá en la máquina de cualquier persona con maven instalado. No hay requisitos adicionales en la configuración del repositorio configurada por el usuario adicional.
- Facilidad de uso: es más fácil para los nuevos desarrolladores recuperar y construir el proyecto porque hay menos configuraciones para configurar.
Tal vez una desventaja es que si la ubicación del repositorio cambia en el futuro, es necesario instalar proxies o es necesario lanzar versiones de parches de software antiguo especificando las nuevas ubicaciones del repositorio (o .m2/settings.xml siempre puede proporcionar repositorios adicionales como un último recurso). Sin embargo, esto parece una ramificación necesaria de una buena reproducibilidad y portabilidad en la administración de versiones en lugar de una estafa.
¿Algún otro pensamiento?
Siempre pongo las URL en el POM y las contraseñas en settings.xml. Si coloca las URL en settings.xml, necesita que sus usuarios actualicen los archivos en sus sistemas locales si su URL cambia alguna vez. Si la URL está especificada en su POM, puede cambiarla e impulsar una nueva versión. Las URL cambian más a menudo de lo que la mayoría puede predecir y llevar a usuarios frustrados cuando se rompe la compilación.
Las contraseñas se guardan en settings.xml por razones obvias. Las contraseñas nunca deben mantenerse en el control de versiones. Necesitará contraseñas para la funcionalidad de implementación mvn para implementar en repositorios remotos.