Las dificultades de Apache Maven

Leyendo la introducción de la presentación que Brett Porter llevará a cabo en el ApacheCon US 2008, me han venido a la mente algunas situaciones que he vivido durante estos años con Apache Maven.

Si mis recuerdos no me fallan, comencé usando Maven 1 a finales del 2004 cuando decidimos usarlo en Opina. Su uso en el proyecto Opina me permitió verdaderamente conocer las bondades de esta herramienta. Por aquella época lo que más se le parecía era Apache Ant. En mi entorno profesional de entonces, lo que más predominaba era usar los IDEs para todo (definir el proyecto, compilación, empaquetado, etc.) y en contadas ocasiones, me encontraba proyectos en los que se usaba Ant. Tiempo después, y cuando mi experiencia con Maven había aumentado, impartí algunas charlas sobre esta herramienta y su beneficios en distintos escenarios.

No debemos perder de vista que los desarrolladores hacían su trabajo correctamente sin Maven ni Ant, y que por tanto, para que éstos decidieran incorporar una nueva herramienta a su día a día, algún beneficio tendrían que recibir a cambio.

Fue trabajando para el Servicio de Informática de la Consejería de Obras Públicas y Transportes (Junta de Andalucía) donde tuve la oportunidad de observar la bienvenida que los desarrolladores le hacía a Maven. He de reconocer que fue aquí donde vi por primera vez usar Maven en la Administración Pública Andaluza. Ahora las cosas han cambiado mucho, hasta tal punto, que los pliegos técnicos de los concursos públicos requieren que sus desarrollos Java usen Maven.

A continuación algunas de las situaciones con las que me he encontrado y que según en qué entornos, han podido suponer una barrera:

  • La calidad y ritmo de documentación (oficial) disminuyó tras la aparición de Maven 2.x.
  • La necesidad de que los ordenadores de los desarrolladores tuvieran que acceder a Internet para trabajar con los repositorios oficiales supuso un inconveniente, especialmente, en los entornos corporativos donde el acceso a Internet está controlado.
  • En relación con el punto anterior, el consumo de ancho de banda. Hoy existen varias alternativas para gestionar repositorios de Maven, y como todos sabéis, uno de sus objetivos es disponer de una caché (y/o mirror) de los repositorios que más empleamos y con esto, ahorrar en ancho de banda. Por aquella época eran muy pocas las opciones en este sentido y además implicaban un nuevo frente de guerra, el responsable de sistemas (o infraestructuras) tenía que dar el visto bueno para instalar un software de este tipo.
  • La mala gestión de los repositorios oficiales. ¿Cuántas veces nos hemos encontrado un artefacto en un repositorio sin su correspondiente POM? Esto se traducía en que ejecutar ciertas tareas tardaban más de lo que la paciencia de un desarrollador es capaz de aguantar estando acostumbrado a pulsar un botón y listo. Cierto, cierto, existe la opción “-O” para trabajar en modo offline. ¿Cuánto tiempo tardaste en darte cuenta de la utilidad de esta opción?
  • Aunque parezca extraño, hay gente que sigue sin ver a Maven más allá de una herramienta de construcción para proyectos Java. Maven también es un framework con el podemos dar solución a necesidades específicas. Evidentemente hay gran cantidad de plugins que constituyen un valor añadido para Maven, pero es importante no perder de vista que podemos extender Maven.
  • Dependencias transitivas. ¿Quién no se ha peleado con las dependencias transitivas? Hoy por hoy la situación está más controlada porque existen herramientas que nos ayudan a analizar las dependencias de nuestro proyecto. Sin embargo, todavía seguimos dependiendo de que ciertos POMs en los repositorios no estén todo lo bien que debieran y que nuestros proyectos si nos descuidamos pasen a pesar 15Mb o más.

Como en casi todo en esta profesión, siempre hay muchas maneras de hacer las cosas, pero siempre hay una que es elegante, inteligente y eficaz. Por eso os recomiendo leer estas dos referencias:

  1. Maven: the definite guide
  2. Better build with Maven

Supongo que me dejo cosas en el tintero, ¿Alguna aportación?

One thought on “Las dificultades de Apache Maven

Leave a Reply

Your email address will not be published. Required fields are marked *