Maven es una herramienta de automatización de compilación que se utiliza principalmente para proyectos Java . Maven también se puede utilizar para crear y gestionar proyectos escritos en C# , Ruby , Scala y otros lenguajes. El proyecto Maven está alojado en la Apache Software Foundation , donde anteriormente formaba parte del Proyecto Jakarta .
Maven aborda dos aspectos de la creación de software: cómo se construye el software y sus dependencias. A diferencia de herramientas anteriores como Apache Ant , utiliza convenciones para el procedimiento de compilación. Sólo es necesario especificar excepciones. Un archivo XML describe el proyecto de software que se está construyendo, sus dependencias de otros módulos y componentes externos, el orden de construcción, los directorios y los complementos necesarios . Viene con objetivos predefinidos para realizar determinadas tareas bien definidas, como la compilación de código y su empaquetado. Maven descarga dinámicamente bibliotecas Java y complementos de Maven desde uno o más repositorios, como el Repositorio Central de Maven 2, y los almacena en una 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 está construido utilizando una arquitectura basada en complementos que le permite utilizar cualquier aplicación controlable a través de entrada estándar. Se mantiene un complemento nativo C / C++ para Maven 2. [3]
Las tecnologías alternativas como Gradle y sbt como herramientas de compilación no se basan en 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 un proyecto de alto nivel de la Apache Software Foundation .
Historial de versiones:
Los proyectos de Maven se configuran utilizando un modelo de objetos de proyecto (POM) en un pom.xmlarchivo.
Archivo de ejemplo:
<project> <!-- la versión del modelo es siempre 4.0.0 para Maven 2.x POM --> <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> mi-aplicación </artifactId> <versión> 1.0 </versión> <!-- dependencias de biblioteca --> <dependencias> <!-- Las coordenadas de una biblioteca requerida. El alcance es "prueba" para indicar que la biblioteca solo se usa para ejecutar pruebas. --> <dependencia> <groupId> org.junit.jupiter </groupId> <artifactId> junit-jupiter-engine </artifactId> <versión> 5.9.1 </versión > <scope> prueba </scope> </ dependencia> </dependencias> </proyecto>Este POM define un identificador único para el proyecto ( coordenadas ) 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 directorios de un proyecto idiomático normal de Maven tiene las siguientes entradas de directorio:
El comando mvn packagecompilará todos los archivos Java, ejecutará las pruebas y empaquetará el código y los recursos entregables target/my-app-1.0.jar(suponiendo que el artefactoId sea mi aplicación y la versión sea 1.0).
Al utilizar Maven, el usuario solo proporciona la configuración para el proyecto, mientras que los complementos configurables realizan el trabajo real de compilar el proyecto, limpiar los directorios de destino, ejecutar pruebas unitarias, generar documentación API, etc. En general, los usuarios no deberían tener que escribir complementos ellos mismos. Compare esto con Ant y make , en el que se escriben procedimientos imperativos para realizar las tareas antes mencionadas.
Un modelo de objetos de proyecto (POM) [7] proporciona toda la configuración para un solo proyecto. La configuración general cubre el nombre del proyecto, su propietario y sus dependencias de otros proyectos. También se pueden configurar fases individuales del proceso de construcción, que se implementan como complementos . Por ejemplo, se puede configurar el complemento del compilador para usar Java versión 1.5 para la compilación, o especificar el empaquetado del proyecto incluso si algunas pruebas unitarias fallan.
Los proyectos más grandes deben dividirse 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 forma 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.
Hay complementos de Maven para crear, probar, administrar el control de 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 sensatas.
Sin embargo, sería engorroso si la secuencia arquetípica de construcción, prueba y empaquetado de un proyecto de software requiriera ejecutar cada objetivo respectivo manualmente:
mvn compiler:compilemvn surefire:testmvn jar:jarEl concepto de ciclo de vida de Maven soluciona este problema.
Los complementos son la forma principal de ampliar Maven. Se puede desarrollar un complemento Maven 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 de Maven para crear una máquina virtual basada en la nube que ejecuta un servidor de aplicaciones . [11]
El ciclo de vida de la construcción es una lista de fases con nombre que se pueden utilizar para ordenar la ejecución del objetivo. Uno de los tres ciclos de vida estándar de Maven es el ciclo de vida predeterminado , que incluye las siguientes fases, realizadas 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:compileestá asociado a la compilefase, mientras que el objetivo surefire:testestá asociado a la testfase. Cuando se ejecuta el mvn testcomando, Maven ejecuta todos los objetivos asociados con cada una de las fases hasta la testfase inclusive. En tal caso, Maven ejecuta el resources:resourcesobjetivo asociado con la process-resourcesfase, luego compiler:compiley así sucesivamente hasta que finalmente ejecuta el surefire:testobjetivo.
Maven también tiene fases estándar para limpiar el proyecto y generar un sitio del proyecto. Si la limpieza fuera parte del ciclo de vida predeterminado, el proyecto se limpiaría cada vez que se construyera. Esto es claramente indeseable, por lo que a la limpieza se le ha dado su propio ciclo de vida.
Los ciclos de vida estándar permiten a los usuarios nuevos en un proyecto la capacidad de construir, probar e instalar con precisión cada proyecto de 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 requerir un jar "uber" que contenga todo el código del proyecto.
Una característica central de Maven es la gestión de dependencias . El mecanismo de manejo de dependencias de Maven está organizado alrededor de un sistema de coordenadas que identifica artefactos individuales, como bibliotecas o módulos de software. El ejemplo de POM anterior hace referencia a las coordenadas JUnit como una dependencia directa del proyecto. Un proyecto que necesita, digamos, 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 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 determinada estructura y un conjunto de flujos de trabajo de tareas compatibles (por ejemplo, obtener recursos del control de fuente, compilar el proyecto, pruebas unitarias, etc.). Si bien la mayoría de los proyectos de software admiten estas operaciones y en realidad 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 para diferentes bibliotecas y marcos de código abierto.
Los proyectos desarrollados en una sola máquina pueden depender unos de otros 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 artefactos creados localmente. El comando Maven mvn installcrea un proyecto y coloca sus archivos 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 dirigidos al lenguaje de programación Java para proporcionar integración de Maven con el mecanismo de compilación y las herramientas de edición de código fuente del IDE, lo que permite a Maven compilar proyectos desde dentro del IDE y también establecer la ruta de clase para finalización de código, resaltado de errores del compilador, etc.
Ejemplos de IDE populares que admiten el desarrollo con Maven incluyen:
Estos complementos también brindan la capacidad de editar el POM o utilizar el POM para determinar el conjunto completo de dependencias de un proyecto directamente dentro del IDE.
Algunas 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 recompilar un único archivo fuente Java después de haberlo editado. Muchos IDE funcionan con un conjunto plano de proyectos en lugar de la jerarquía de carpetas preferida por Maven. Esto complica el uso de sistemas SCM en IDE cuando se usa Maven. [16] [17] [18]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
{{cite book}}: Mantenimiento CS1: otros ( enlace )