Necesita materiales de presentación para convencer a un cliente de que use Maven

Question

Mi cliente necesita un inventario más organizado de todas las bibliotecas de terceros (como archivos JAR) que se utilizan en la producción para sus proyectos. Estoy involucrado con varios de sus proyectos basados ​​en Java. Su inventario no se ha mantenido de forma consistente en el pasado y ha llegado el momento de dar cuenta de todas las bibliotecas que se están utilizando actualmente (¡hay bastantes!) Y de hacer cumplir un proceso estructurado para introducir nuevas bibliotecas en el entorno de compilación.

He intentado presentar la idea de utilizar Maven y Artifactory en su proceso de compilación para aprovechar la capacidad de esas herramientas para gestionar un repositorio de bibliotecas binarias y manejar dependencias de bibliotecas transitivas. El cliente es resistente a la sugerencia porque creen que les creará más trabajo para mantener un servidor de Artifactory y aprender los conceptos básicos de Maven.

Actualmente, sus proyectos Java están construidos con scripts Ant. Las dependencias transitivas se manejan en gran medida por ensayo y error. El inventario de bibliotecas actualmente en uso se mantiene a mano y los archivos binarios se almacenan en un repositorio de Subversion. El cliente reconoce que esto necesita mejorarse, pero las sugerencias actuales de mejora implican enfoques más ad hoc "adminístrelo a mano".

Quiero convencer al cliente de que una combinación de Maven y Artifactory es una solución viable y lista para usar para sus necesidades de administración de bibliotecas Java. ¿Alguien puede dirigirme a literatura/materiales que pueda usar para crear una presentación para mi cliente sobre las características y fortalezas de Maven y Artifactory?

Cualquier otro argumento/sugerencia/etc. que me ayudaría en esto también sería apreciado.

Answer 1

Quiero convencer al cliente de que una combinación de Maven y Artifactory es una solución comercial viable para sus necesidades de administración de la biblioteca Java.

Como se señaló en un comentario, su cliente no necesita necesariamente adoptar plenamente Maven para beneficiarse de la gestión de la dependencia, se podría adaptar los guiones de hormigas existentes para utilizar el Maven Ant tasks o la hiedra. Esto podría ser menos aterrador y ya eliminar el dolor.

En cuanto a la forma en que maneja las dependencias Maven, yo simplemente explicar que:

• Un artefacto se identifica por las coordenadas (groupId, artifactId, versión).
• Esto permite almacenarlos almacenados usando una estructura de directorio estandarizada (un repositorio)
• Una dependencia es más que un JAR: es un JAR con un POM que permite cosas como la resolución de dependencias transitivas.

Y los beneficios de una solución de este tipo de gestión de la dependencia son:

• sin meterse con dependencias, que se identifican de forma única (no más "qué versión es esa?"Síndrome)
• datos no más binarios en el VCS (de pago más rápido, menos espacio)
• más fácil reutilización de artefactos entre los proyectos (no más tarros enviados por correo electrónico)
• más fácil gestión con la resolución dependencia transitiva

Y porque no quiere depender de los repositorios públicos, porque es necesario para almacenar sus propios artefactos, necesita un repositorio empresarial Mi elección personal sería Nexus:.

• porque es de archivos basado en (a diferencia de Artifactory, y yo no quiero poner mis artefactos en una base de datos)
• porque es fácil de instalar/usar
• porque es fácil de administrar

Éstos son algunos recursos sobre Nexus (lo siento, simplemente no uso Artifactory):

• Should we use Nexus or Artifactory for a Maven Repo?
• Ning’s Migration from Artifactory to Nexus Professional
• From Apache Archiva to Sonatype Nexus

Y por si acaso, aquí material de presentación sobre Maven:

• Varios presentations por Arnaud Héritier.
• Maven 2.x por Jason van Zyl.
• Maven 2.0 - Improve your build patterns por Vincent Massol.
• 3.5. Core Concepts en la guía definitiva Maven