Consejos para mantener un repositorio Maven interno?

Question

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

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

ACTUALIZACIÓN: Hemos puesto de pie a Nexus y estamos muy contentos con él, hemos seguido la mayoría de las directrices de Sal y no hemos tenido ningún problema. Además, hemos restringido el acceso de despliegue y la compilación/despliegue automatizados de artefactos de instantáneas a través de un servidor Hudson CI. Hudson puede analizar todas las dependencias de proyectos ascendentes/descendentes, por lo que si un problema de compilación, falla de prueba o alguna otra violación hace que la construcción se rompa, no se realizará ninguna implementación. Estate cansado de realizar implementaciones de instantáneas en Maven2/Maven3, ya que los metadatos han cambiado entre las dos versiones. La estrategia de implementación de instantáneas "solo Hudson" mitigará esto. No utilizamos el complemento de versión, pero hemos escrito algunas tuberías alrededor del Versions plugin cuando vamos a mover una instantánea para liberarla. 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 tuve que retocar algunas de esas configuraciones para que indexe completamente nuestras instantáneas internas). También le recomendaría implementar una jarra fuente con sus artefactos como práctica estándar si está interesado en hacer esto. Configuramos eso en un súper POM.

Update2: Me he encontrado this Sonatype whitepaper que detalla las diferentes etapas de adopción/madurez, cada uno con diferentes objetivos de uso para un administrador de repositorios Maven.

Answer 1

Recomendaría configurar un servidor nexus con al menos cuatro repositorios. No recomendaría el artefacto. 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 la versión de Sonatype. La integración de LDAP paga por sí misma.

1. Interno de Versión
2. instantánea interna
3. Partido tercera interno de código utilizado en casa que proviene de fuentes externas, o para las versiones aprobadas de 3 ª parte. Pon los controladores JDBC, javax. * Cosas y cosas de clientes y socios aquí.
4. La representación externa de proxy común para todas las fuentes habituales como m2, Codehaus etc

Configurar Nexus para hacer lo siguiente para los repositorios internos

1. eliminar instantáneas de edad en intervalos regulares
2. Eliminar Instantáneas en la versión
3. Crear archivos de índice. Esto acelera las construcciones locales también

Disponen de un archivo settings.xml común que utiliza estas cuatro y solo estas cuatro fuentes. Si necesita personalizar más allá, intente guardar parte común del archivo de configuración y utilice los perfiles para las diferencias. No permita que sus clientes simplemente modifiquen su configuración o terminará con un código que se compila en una máquina pero no en otra máquina.

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

No mezcle los artefactos internos y de terceros en el mismo repositorio. Nexus le permite agregar archivos jar a un repositorio interno a través de una guía 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 cuando se compara con la mayoría de los software empresariales .

definir una matriz común POM que define la instantánea interna y suelte repos a través de la etiqueta dedistributionManagement. Sé que mucha gente te dice que no hagas esto. Y aunque admito abiertamente que hay todo tipo de problemas al hacer esto, funciona bien si los clientes solo crearán lanzamientos e instantáneas para implementar en un único repositorio interno.

Si usted tiene un mal gestionados Maven repositorio de existente, crear una 5ª repos llamados Legado y poner todo el repos 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 moverse y actualizar sus poms.

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

Answer 2

Quizás esto es obvio, pero, para la reproducibilidad, los desarrolladores nunca deben sobrescribir artefactos, deben ser versiones nuevas.

Esto también se aplica a los repositorios en sentido ascendente. Si descarga Apache-commons versión 1.2.3, realmente nunca debería volver a descargarla. Las soluciones provienen de versiones posteriores, no aplicadas a versiones existentes.

Answer 3

Use Artifactory.

Answer 4

Definitivamente use Nexus. : P

He usado tanto Nexus como Artifactory. La interfaz para Nexus es mucho más robusta, es mucho más configurable y, por supuesto, está escrita por Sonatype, que representa casi todo lo que Maven hace bien.

Dicho esto, Artifactory es decente y viable.

• A review of Nexus vs. Artifactory
• Oh my! Of course, here's a SO quesiton about the matter.
• Sonatype does a feature comparison
• jFrog (maker of Artifactory) does a feature comparison

Answer 5

estoy usando Artifactory mí 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 características adecuada.

Aquí hay algunas cosas de la parte superior de la cabeza que me gusta de Artifactory (tener en cuenta Nexus pueden tener estas características también):

1. interfaz Web 2.0 Niza.
2. La posibilidad de importar su repositorio Maven local para ayudarlo a comenzar.
3. Facilidad de integración con 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 desea asegurarse de haber tomado la decisión correcta, le recomiendo probar ambas, y decidir por sí mismo cuál le gusta más .

Answer 6

Otra cosa a tener en cuenta:

http://archiva.apache.org/

Answer 7

Como los del pregunta original (aspectos técnicos a considerar en la construcción de un repositorio M2), que recomendaría la creación de sólo lectura de usuario para navegar por el repositorio y usuario administrativo por administrador (dicho esto: un usuario de solo lectura para todos los 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 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 la búsqueda de artefactos en el repositorio se realice más rápidamente.

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

Para el registro, estoy usando tanto Nexus como Artifactory; Puedo afirmar 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 (gratuita) de la comunidad de Artifactory. Excluyendo la impresionante interfaz de usuario web 2 de Artifactory, sus características principales, como la gestión de seguridad, las copias de seguridad periódicas y los problemas de accesibilidad, van más allá de las de Nexus.