Maven es una herramienta de automatización de compilación que se utiliza principalmente para proyectos Java . Maven también se puede utilizar para compilar y administrar proyectos escritos en C# , Ruby , Scala y otros lenguajes. El proyecto Maven está alojado por The Apache Software Foundation , donde anteriormente formaba parte del Proyecto Jakarta .
Maven aborda dos aspectos de la creación de software: cómo se crea el software y sus dependencias. A diferencia de herramientas anteriores como Apache Ant , utiliza convenciones para el procedimiento de creación. Solo es necesario especificar excepciones. Un archivo XML describe el proyecto de software que se está creando, sus dependencias de otros módulos y componentes externos, el orden de creación, los directorios y los complementos necesarios . Viene con objetivos predefinidos para realizar ciertas tareas bien definidas, como la compilación de código y su empaquetado. Maven descarga dinámicamente bibliotecas Java y complementos Maven de uno o más repositorios, como el Repositorio central de Maven 2, y los almacena en un caché local. [2] Este caché local de artefactos descargados también se puede actualizar con artefactos creados por proyectos locales. Los repositorios públicos también se pueden actualizar.
Maven se ha creado con una arquitectura basada en complementos que le permite utilizar cualquier aplicación que se pueda controlar mediante una entrada estándar. Se mantiene un complemento nativo de C / C++ para Maven 2. [3]
Las tecnologías alternativas como Gradle y sbt como herramientas de compilación no dependen de XML , pero mantienen los conceptos clave introducidos por Maven. Con Apache Ivy , también se desarrolló un administrador de dependencias dedicado que también admite repositorios Maven. [4]
Apache Maven tiene soporte para compilaciones reproducibles . [5] [6]
Maven fue creado por Jason van Zyl en 2002 y comenzó como un subproyecto de Apache Turbine . En 2003, Maven fue aceptado como proyecto de nivel superior de la Apache Software Foundation .
Historial de versiones:
Los proyectos Maven se configuran utilizando un modelo de objetos de proyecto (POM) en un pom.xmlarchivo.
Archivo de ejemplo:
<project> <!-- la versión del modelo siempre es 4.0.0 para los POM de Maven 2.x --> <modelVersion> 4.0.0 </modelVersion> <!-- coordenadas del proyecto, es decir, un grupo de valores que identifican de forma única este proyecto --> <groupId> com.mycompany.app </groupId> <artifactId> my-app </artifactId> <version> 1.0 </version> <!-- dependencias de la biblioteca --> <dependencias> <!-- Las coordenadas de una biblioteca requerida. El alcance es 'test' para indicar que la biblioteca solo se usa para ejecutar pruebas. --> <dependency> <groupId> org.junit.jupiter </groupId> <artifactId> junit-jupiter-engine </artifactId> <version> 5.9.1 </version> <scope> test </scope> </dependency> </dependencias> </proyecto>Este POM define un identificador único para el proyecto ( coordinates ) y una única dependencia de la biblioteca JUnit . Sin embargo, eso ya es suficiente para construir el proyecto y ejecutar las pruebas unitarias asociadas con el proyecto. Maven logra esto adoptando la idea de Convención sobre Configuración , es decir, Maven proporciona valores predeterminados para la configuración del proyecto.
La estructura de directorio de un proyecto Maven idiomático normal tiene las siguientes entradas de directorio:
El comando mvn packagecompilará todos los archivos Java, ejecutará todas las pruebas y empaquetará el código entregable y los recursos en target/my-app-1.0.jar(asumiendo que el artefactoId es my-app y la versión es 1.0).
Al utilizar Maven, el usuario solo proporciona la configuración para el proyecto, mientras que los complementos configurables hacen el trabajo real de compilar el proyecto, limpiar los directorios de destino, ejecutar pruebas unitarias, generar documentación de API, etc. En general, los usuarios no deberían tener que escribir complementos por sí mismos. Comparemos esto con Ant y make , en los que uno escribe procedimientos imperativos para realizar las tareas mencionadas anteriormente.
Un modelo de objetos de proyecto (POM) [7] proporciona toda la configuración para un único proyecto. La configuración general cubre el nombre del proyecto, su propietario y sus dependencias en otros proyectos. También se pueden configurar fases individuales del proceso de compilación, que se implementan como complementos . Por ejemplo, se puede configurar el complemento del compilador para que utilice la versión 1.5 de Java para la compilación, o especificar el empaquetado del proyecto incluso si algunas pruebas unitarias fallan.
Los proyectos más grandes se deben dividir en varios módulos o subproyectos, cada uno con su propio POM. Luego se puede escribir un POM raíz a través del cual se pueden compilar todos los módulos con un solo comando. Los POM también pueden heredar la configuración de otros POM. Todos los POM heredan del Super POM [8] de manera predeterminada. El Super POM proporciona una configuración predeterminada, como directorios de origen predeterminados, complementos predeterminados, etc.
La mayor parte de la funcionalidad de Maven se encuentra en complementos . Un complemento proporciona un conjunto de objetivos que se pueden ejecutar mediante el comando mvn [plugin-name]:[goal-name]. Por ejemplo, un proyecto Java se puede compilar con el objetivo de compilación del complemento del compilador [9] ejecutando mvn compiler:compile.
Existen complementos de Maven para compilar, probar, administrar el control de código fuente, ejecutar un servidor web, generar archivos de proyecto Eclipse y mucho más. [10] Los complementos se introducen y configuran en una sección <plugins> de un pom.xmlarchivo. Algunos complementos básicos se incluyen en cada proyecto de forma predeterminada y tienen configuraciones predeterminadas razonables.
Sin embargo, sería complicado si la secuencia de construcción arquetípica de crear, probar y empaquetar un proyecto de software requiriera ejecutar cada objetivo respectivo manualmente:
mvn compiler:compilemvn surefire:testmvn jar:jarEl concepto de ciclo de vida de Maven aborda este problema.
Los complementos son la forma principal de ampliar Maven. El desarrollo de un complemento Maven se puede realizar ampliando la clase org.apache.maven.plugin.AbstractMojo. En el artículo Automatizar el desarrollo y la gestión de máquinas virtuales en la nube se proporciona un código de ejemplo y una explicación de un complemento Maven para crear una máquina virtual basada en la nube que ejecute un servidor de aplicaciones . [11]
El ciclo de vida de la compilación es una lista de fases con nombre que se pueden utilizar para dar orden a la ejecución de un objetivo. Uno de los tres ciclos de vida estándar de Maven es el ciclo de vida predeterminado , que incluye las siguientes fases, ejecutadas en el orden indicado: [12]
Los objetivos proporcionados por los complementos se pueden asociar con diferentes fases del ciclo de vida. Por ejemplo, de forma predeterminada, el objetivo compiler:compilese asocia con la compilefase, mientras que el objetivo surefire:testse asocia con la testfase. Cuando mvn testse ejecuta el comando, Maven ejecuta todos los objetivos asociados con cada una de las fases hasta la testfase incluida. En tal caso, Maven ejecuta el resources:resourcesobjetivo asociado con la process-resourcesfase, luego compiler:compile, y así sucesivamente hasta que finalmente ejecuta el surefire:testobjetivo.
Maven también tiene fases estándar para limpiar el proyecto y para generar un sitio de proyecto. Si la limpieza fuera parte del ciclo de vida predeterminado, el proyecto se limpiaría cada vez que se creara. Esto es claramente indeseable, por lo que se le ha dado a la limpieza su propio ciclo de vida.
Los ciclos de vida estándar permiten a los usuarios nuevos en un proyecto la capacidad de crear, probar e instalar con precisión cada proyecto Maven emitiendo un único comando mvn install. De forma predeterminada, Maven empaqueta el archivo POM en archivos JAR y WAR generados. Herramientas como diet4j [13] pueden usar esta información para resolver y ejecutar de forma recursiva módulos Maven en tiempo de ejecución sin necesidad de un archivo jar "super" que contenga todo el código del proyecto.
Una característica central de Maven es la gestión de dependencias . El mecanismo de gestión de dependencias de Maven está organizado en torno a un sistema de coordenadas que identifica artefactos individuales, como bibliotecas de software o módulos. El ejemplo de POM anterior hace referencia a las coordenadas de JUnit como una dependencia directa del proyecto. Un proyecto que necesita, por ejemplo, la biblioteca Hibernate simplemente tiene que declarar las coordenadas del proyecto de Hibernate en su POM. Maven descargará automáticamente la dependencia y las dependencias que Hibernate mismo necesita (llamadas dependencias transitivas ) y las almacenará en el repositorio local del usuario. El Repositorio central de Maven 2 [2] se utiliza de forma predeterminada para buscar bibliotecas, pero se pueden configurar los repositorios que se utilizarán (por ejemplo, repositorios privados de la empresa) dentro del POM.
La diferencia fundamental entre Maven y Ant es que el diseño de Maven considera que todos los proyectos tienen una estructura determinada y un conjunto de flujos de trabajo de tareas compatibles (por ejemplo, obtener recursos del control de código fuente, compilar el proyecto, realizar pruebas unitarias, etc.). Si bien la mayoría de los proyectos de software admiten estas operaciones y tienen una estructura bien definida, Maven requiere que esta estructura y los detalles de implementación de la operación se definan en el archivo POM. Por lo tanto, Maven se basa en una convención sobre cómo definir proyectos y en la lista de flujos de trabajo que generalmente se admiten en todos los proyectos. [14]
Existen motores de búsqueda como The Central Repository Search Engine, [15] que se pueden utilizar para encontrar coordenadas de diferentes bibliotecas y marcos de código abierto.
Los proyectos desarrollados en una sola máquina pueden depender entre sí a través del repositorio local. El repositorio local es una estructura de carpetas simple que actúa como caché para las dependencias descargadas y como lugar de almacenamiento centralizado para los artefactos creados localmente. El comando Maven mvn installcrea un proyecto y coloca sus binarios en el repositorio local. Luego, otros proyectos pueden utilizar este proyecto especificando sus coordenadas en sus POM.
Existen complementos para varios entornos de desarrollo integrados (IDE) populares que apuntan al lenguaje de programación Java para proporcionar la integración de Maven con el mecanismo de compilación del IDE y las herramientas de edición de código fuente, lo que permite a Maven compilar proyectos desde dentro del IDE y también establecer la ruta de clase para completar el código, resaltar errores del compilador, etc.
Algunos ejemplos de IDE populares que admiten el desarrollo con Maven incluyen:
Estos complementos también brindan la capacidad de editar el POM o usar el POM para determinar el conjunto completo de dependencias de un proyecto directamente dentro del IDE.
Algunas de las características integradas de los IDE se pierden cuando el IDE ya no realiza la compilación. Por ejemplo, JDT de Eclipse tiene la capacidad de volver a compilar un único archivo fuente de Java después de haberlo editado. Muchos IDE trabajan con un conjunto plano de proyectos en lugar de la jerarquía de carpetas que prefiere Maven. Esto complica el uso de sistemas SCM en IDE cuando se utiliza Maven. [16] [17] [18]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
{{cite book}}: Mantenimiento de CS1: otros ( enlace )