Recupero un post que ha estado en borradores un largo tiempo, pese a que ahora esté de moda Gradle 🙂
Teniendo en cuenta que vengo del mundo PHP, estaba empezando a documentarme sobre Apache Maven (una herramienta para la gestión -compilación, reporting y documentación- de proyectos Java) y sin tener demasiada idea, me ha parecido que tiene cierta similitud con Apache Ant. Como no podía ser de otra manera, no soy el primero que se ha preguntado en qué se diferencia Apache Ant de Apache Maven, y en StackOverflow dan un par de respuestas interesantes:
«Ant is an imperative build system, whereas Maven is a declarative build system» -> Un script ant le dice a ant qué ha de hacer, mientras que un script maven le dice a maven qué es lo que quieres conseguir, y maven se encarga de hacerlo.
Maven nació con la intención de estandarizar la creación de proyectos Java, definir de forma clara en qué consiste un proyecto determinado, facilitar la publicación de la información del proyecto y permitir la compartición de los ficheros JAR entre diferentes proyectos.
Fuente: https://maven.apache.org/what-is-maven.html
Instalación de Apache Maven
Aunque podemos encontrar Maven en los repositorios oficiales de Fedora, en la web de Maven describen el siguiente proceso de instalación:
Descomprimimos y ubicamos el directorio de Apache Maven:
wget http://mirror.cogentco.com/pub/apache/maven/maven-3/3.3.1/binaries/apache-maven-3.3.1-bin.tar.gz
tar -zxvf apache-maven-3.3.1-bin.tar.gz
sudo mv apache-maven-3.3.1 /usr/local/apache-maven
Posteriormente, añadimos el directorio «bin» de Maven al Path:
export PATH=$PATH:/usr/local/apache-maven/bin
Maven necesita contar con el JDK de Java, pues no basta únicamente con el JRE. Hay que indicarle al JAVA_HOME la ruta a la ubicación del JDK. En mi caso:
export JAVA_HOME=/usr/java/jdk1.8.0_31
Podremos verificar la correcta instalación de Maven ejecutando:
mvn --version
Fuente:
http://maven.apache.org/download.cgi#Installation
Artifacts
Un build de Maven producirá uno o más «artifacts«. Un artifact no es más que un fichero .jar (también pueden ser de otros tipos, como .war o .ear) resultado de la compilación del proyecto, que se deploya en el respositorio de Maven.
POM.xml
El fichero pom.xml (Project Object Model), es la pieza central de la configuración de un proyecto Maven. Contiene toda la información importante del proyecto, como por ejemplo las dependencias del proyecto, los plugins o los «goals» («objetivos» que queremos alcanzar) que pueden ejecutarse, e incluso la versión del proyecto, la descripción, developers, mailing lists…
El «Super POM» de Maven es el POM por defecto de Maven. Todos los ficheros pom.xml, a no ser que explícitamente especifiquen lo contrario, extienden del Super POM. [Más info]. Así pues, en un fichero pom.xml, por lo menos deberemos especificar lo siguiente:
- modelVersion: indica qué versión del Object Model usa este POM. Es poco frecuente que cambie la versión, pero aun así este parámetro es obligatorio. En la documentación oficial indica que actualmente debe setearse a «4.0.0».
- groupId: identificador único para la organización o grupo que ha creado el proyecto. Típicamente se base en el FQDN de tu organización. P.ej. «org.apache.maven.plugins».
- artifactId: indica la base del nombre (única) para el artifact principal que generará el proyecto. El proyecto puede tener artifacts secundarios que también incluirán esta base como parte de su nombre. Un artifact producido por Maven debería tener la forma <artifactId>-<version>.<extension>, p.ej. «myapp-1.0.jar».
- version: indica la versión del artifact generado por el proyecto. Si la versión contiene la palabra «SNAPSHOT», indicará que el proyecto está en estado de desarrollo.
El resto de elementos del pom.xml, si no los indicamos, cojerán los valores por defecto del Super POM.
Es importante saber que el «fully qualified artifact name» lo forman los valores anteriores, tal que así: <groupId>:<artifactId>:<version>. Un ejemplo (cogido directamente de la documentación oficial) sería «com.mycompany.app:my-app:1».
Dependencias y módulos
También será habitual encontrar módulos y dependencias.
Para las dependencias, puede resultar muy útil configurar la sección «dependencyManagement» la cual permite definir las versiones de las dependencias en el parent. Así, podremos prescindir de la versión en las dependencias de los módulos definidas en la sección «dependencyManagement» del parent, pues estas dependencias usarán la versión definida ahí, manteniendo así las versiones en un único punto.
Si tenemos módulos y dependencias, cuidado con la herencia de configuraciones comunes (dependencias, plugins, recursos…).
Fuentes:
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
Plugins
Tal y como indica la documentación oficial, se podría decir que Maven es un framework que ejecuta plugins. Un plugin no es más que un conjunto de objetivos (goals) con un mismo propósito. P.ej. el plugin «jboss-maven-plugin» tiene varios objetivos para trabajar con Jboss.
Si como proponen en la guía «Maven en 5 minutos» ejecutamos el siguiente comando desde el que será el directorio que hará de repositorio…
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
…le estaremos indicando a Maven que se ejecute el objetivo «generate» del plugin (archetype) «archetype», al cual le pasamos además varios parámetros.
A partir de aquí, las configuraciones dependerán de nuestro proyecto, los plugins y de cómo lo enfoquemos.
Fuentes:
https://www.youtube.com/watch?v=VOkgaq__Ff8
http://www.genbetadev.com/java-j2ee/introduccion-a-maven
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
http://maven.apache.org/guides/getting-started/index.html