Consejos para mantener un repositorio interno de Maven?

Question

Estoy interesado en mantener un Maven 2 repositorio para mi organización. ¿Cuáles son algunos de los consejos y trampas que ayudarían?

¿Cuáles son las pautas que deben seguir los usuarios al configurar estándares para descargar o publicar sus propios artefactos en el repositorio al liberar su código? ¿Qué tipo de gobierno / reglas tiene para este tipo de cosas? ¿Qué incluye al respecto en la guía / documentación de su desarrollador?

ACTUALIZACIÓN : Hemos defendido Nexus y estamos muy contentos con él, seguimos la mayoría de las pautas de Sal y no hemos tenido ningún problema. Además, hemos restringido el acceso a la implementación y la creación / implementación automatizada de artefactos de instantáneas a través de un servidor Hudson CI. Hudson puede analizar todas las dependencias del proyecto en sentido ascendente / descendente, por lo que si un problema de compilación, una falla en la prueba o alguna otra violación provocan que la compilación se rompa, no ocurrirá ninguna implementación. Tenga cuidado de hacer implementaciones de instantáneas en Maven2 / Maven3, ya que los metadatos han cambiado entre las dos versiones. El " Hudson solamente " La estrategia de implementación de la instantánea mitigará esto. No utilizamos el complemento de lanzamiento, pero hemos escrito algunas tuberías alrededor del complemento de versiones cuando va a mover una instantánea para liberar. También usamos m2eclipse y parece funcionar muy bien con Nexus, ya que desde el archivo de configuración puede ver Nexus y sabe indexar la información de artefactos para buscar desde allí. (Aunque he tenido que modificar algunas de esas configuraciones para que indexe completamente nuestras instantáneas internas). También te recomiendo que despliegues un jar fuente con tus artefactos como práctica estándar si estás interesado en hacer esto. Configuramos eso en un super POM.

ACTUALIZACIÓN2 : me he encontrado con este documento técnico de Sonatype que detalla diferentes etapas de adopción / madurez, cada una con diferentes objetivos de uso para un administrador de repositorio de Maven.

Answer 1

Recomendaría configurar un servidor nexus con al menos cuatro repositorios. No recomendaría artefactos. La versión gratuita de nexus está perfectamente bien para un equipo de desarrollo de menos de 20 en menos de tres grupos. Si tiene más usuarios que eso, hágase un favor y pague por el lanzamiento de Sonatype. La integración LDAP se paga sola.

1. Lanzamiento interno
2. Instantánea interna
3. Terceros internos para el código utilizado en casa que proviene de fuentes externas, o para versiones de terceros aprobadas. Ponga los controladores JDBC, javax. * Cosas y cosas de clientes y socios aquí.
4. Proxies externos proxy común para todas las fuentes habituales como m2, codehaus, etc.

Configure Nexus para hacer lo siguiente para repositorios internos

1. Eliminar instantáneas antiguas a intervalos regulares
2. Eliminar instantáneas en el lanzamiento
3. Crear archivos de índice. Esto también acelera las construcciones locales

Tenga un archivo settings.xml común que use estas cuatro y solo estas cuatro fuentes. Si necesita personalizar más allá de esto, intente mantener una parte común de la configuración archivar y usar los perfiles para las diferencias. No permita que sus clientes solo apliquen su propia configuración o terminará con un código que se construye en una máquina pero no en otra máquina.

Proporcione un proxy común para sus clientes. en Nexus, puede agregar un grupo de proxies a las fuentes comunes de Maven (Apache, JBoss, Codehaus) y tener un solo proxy expuesto a los clientes internos . Esto hace que agregar y eliminar fuentes de sus clientes sea mucho más fácil.

No mezcle artefactos internos y de terceros en el mismo repositorio. Nexus le permite agregar frascos a un repositorio interno a través de una interfaz gráfica de usuario web. Recomiendo esto como la forma de agregar sus controladores JDBC y otro código externo a terceros. La interfaz de usuario es bastante agradable de usar en comparación con la mayoría de software empresarial .

Defina un POM principal común que defina la instantánea interna y libere repositorios a través de la etiqueta distributionManagement . Sé que mucha gente te dice que no hagas esto. Y aunque admito libremente que hay todo tipo de problemas al hacer esto, funciona bien si los clientes solo crearán versiones e instantáneas para implementar en un único repositorio interno.

Si tiene un repositorio Maven existente mal administrado , cree un quinto repositorio llamado Legacy y coloque todos los repositorios allí. Configure una tarea cron para eliminar archivos antiguos del legado una vez que tengan un año. Eso les da a todos un año para dejarlo y actualizar sus poms.

Establezca una convención de nomenclatura fácil para los artefactos internos. Prefiero GroupID de Department.Function.Project y ArtifactId para ese componentName . Para los repositorios internos, es probable que com / org / net y el nombre de la empresa sean irrelevantes. Y mal si la empresa cambia su nombre. Es mucho menos probable que se cambie el nombre del departamento de ventas, contabilidad o inventario.

Answer 2

Definitivamente use Nexus . : P

He usado Nexus y Artifactory. La interfaz para Nexus es mucho más robusta, es mucho más configurable y, por supuesto, escrita por Sonatype , que se arrepiente de casi todo Maven bien.

Dicho esto, Artifactory es decente y viable.

• Una revisión de Nexus vs. Artifactory
• ¡Oh! Por supuesto, aquí hay una pregunta SO sobre el asunto.
• Sonatype realiza una comparación de características
• jFrog (fabricante de Artifactory) hace una comparación de características

Answer 3

Utilice Artifactory .

Answer 4

Estoy usando Artifactory yo mismo, y me encanta la interfaz de usuario y la facilidad de implementación / mantenimiento. Dicho esto, nunca he usado Nexus, y realmente no puedo ayudarte con una comparación de funciones adecuada.

Aquí hay algunas cosas que realmente me gustan de Artifactory (tenga en cuenta que Nexus también puede tener estas características):

1. Bonita interfaz Web 2.0.
2. La capacidad de importar su repositorio local de Maven para ayudarlo a comenzar.
3. Facilidad de integración con los servidores LDAP existentes para la seguridad (soy un gran admirador de un único repositorio para almacenar credenciales).

Dado que en realidad solo hay dos implementaciones principales de Maven Repository, si realmente quieres asegurarte de haber tomado la decisión correcta, te recomiendo probar ambas y decidir por ti mismo cuál te gusta más.

Answer 5

Quizás esto sea obvio, pero, para la reproducibilidad, los desarrolladores nunca deberían sobrescribir los artefactos, deberían ser versiones nuevas.

Esto también se aplica a los repositorios ascendentes. Si descarga Apache-commons versión 1.2.3, nunca debería volver a descargarlo. Las correcciones provienen de versiones posteriores, no aplicadas a versiones existentes.

Answer 6

Algo más a considerar:

http://archiva.apache.org/

Answer 7

Como la PREGUNTA ORIGINAL (cuestiones técnicas a considerar al construir un repositorio M2), recomendaría crear un usuario de solo lectura para explorar el repositorio y el usuario administrativo por administrador (que decía: una lectura -solo usuario para todos aquellos usuarios que no son administradores). Además, recomendaría generar imágenes de respaldo periódicamente (¿quizás una vez al día?). Muy importante tanto si su repositorio es grande o si instala sus propios artefactos de vez en cuando.

Por último, pero no menos importante, al agregar nuevos repositorios remotos, debe agregar filtros de inclusión / exclusión para que se realice una búsqueda de artefactos en el repositorio más rápidamente.

Hay muchos otros problemas a considerar, pero estos son los problemas principales que he encontrado al administrar un repositorio interno de Maven.

Para el registro, estoy usando Nexus y Artifactory; Puedo decir claramente que si bien Nexus es muy simple y operativo (aunque a veces tengo problemas con el proceso de instalación en Ubuntu), su versión gratuita no puede competir con la edición comunitaria (gratuita) de Artifactory. Excluyendo la increíble interfaz de usuario web 2 de Artifactory, sus características principales, como la administración de seguridad, las copias de seguridad periódicas y los problemas de accesibilidad están mucho más allá de las de Nexus.