Maven nos ayuda a crear los directorios de nuestro proyecto y con las tareas

habituales que se realizan en él, como compilado, generar jar, documentación,

distribuir, dependencias con otros jar, etc.

Dice que lo primero que podemos hacer es crear un proyecto nuevo con el siguiente
comando:
mvn archetype:create -DgroupId=chuidiang.ejemplos -DartifactId=EjemploMaven

El primer parametro es el plugin para crear proyectos, despues esta el grupo de

proyectos al que pertenece este, y por ultimo el nombre del proyecto. Éste ultimo
va a ser el nombre de la carptea raiz del proyecto y del jar que se genere cuando
hagamos el package
Si uso arhcetype es como una plantilla, mas que nada para ejecutarlo desde la linea
de comando y que se creen todos los directorios y archivos de configuracion y
descargue todos los artefactors necesarios configurados por defecto.

<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.13</version>
<scope>compile</scope>
</dependency>

En https://mvnrepository.com/artifact/org.apache.ant/ant/1.10.5 puedo fijarme lo

que puse arriba para cada dependencia que necesite. Maven descarga e instala la
libreria que yo le diga en .m2
En https://search.maven.org tambien

Maven se encarga de simplificar el procesos de build, que consistiria en compilar y

generar ejecutables a partir del código fuente
Soluciona el problema de que Si queríamos compilar y generar ejecutables de un
proyecto, teníamos que analizar qué partes de código se debían compilar, qué
librerías utilizaba el código, dónde incluirlas, qué dependencias de compilación
había en el proyecto…

Podria probar poniendo el atributo packaging en el pom a ver si toma .exp

Las librerias del proyecto estarian en: ${ raíz del proyecto }/src/main/resource

En Maven, la ejecución de un archivo POM siempre genera un "artefacto".

tenemos una sección de dependencias, estos son las librerías que necesitamos
para compilar el proyecto.

Puedo probar cambiando o agregando repositorio central de Maven (el que viene por
defautl es http://repo1.maven.org/maven2)
https://stackoverflow.com/questions/2361294/how-do-i-get-maven-to-use-the-correct-
repositories -> para ver como ver el repositorio central
Ejemplo:
<repositories>
<repository>
<id>org.springframework.maven.milestone</id>
<url>http://maven.springframework.org/milestone</url>
 </repository>
</repositories>

Haciendo esto puedo agregar la dependency que queria

Podríamos decir, que Maven es una herramienta capaz de gestionar un proyecto

software completo, desde la etapa en la que se comprueba que el código es correcto,
hasta que se despliega la aplicación, pasando por la ejecución de pruebas y
generación de informes y documentación. Para ello Maven define 3 ciclos de build.
El de por deffecto es:
– Validate: Validar que el proyecto es correcto.
– Compile
– Test: Probar el código fuente usando un framework de pruebas unitarias.
– Package: Empaquetar el código compilado y transformarlo en algún formato tipo
.jar o .war.
– Integration-test: Procesar y desplegar el código en algún entorno donde se puedan
ejecutar las pruebas de integración.
– Verify que el código empaquetado es válido y cumple los criterios de calidad
– Install el código empaquetado en el repositorio local de Maven, para usarlo como
dependencia de otros proyectos.
– DDeploy: esplegar el código a un entorno
Existen 3 ciclos de vida en Maven 2:
•clean. Elimina las clases compiladas y los archivos binarios generados del
proyecto
•default. Genera los archivos binarios (artefactos) de nuestro proyecto
•site. Genera archivos html que describen nuestro proyecto

mvn clean install -> supuestamente para limpiar builds anteriores

NOTA: me doy cuenta que tal vez el package que estoy usando ahora realmente deba
mandarlo a .m2, no hacer uno por afuera como lo estoy haciendo, usando .exp en el
atributo packaging.

Existen 6 scopes para las dependencias en Maven:

•compile. Por defecto, si no se especifica se usará éste scope. Estas
dependencias se usan en el classpath del proyecto y serán incluidas en el artefacto
final.
•provided. Estas dependencias se usan durante la fase compile y test. Pero no
se incluyen el artefacto final. Es muy usado por ejemplo para incluir los jar de
J2EE (como servlet-api.jar) ya que son necesarios para compilar pero ya están en tu
servidor Java, por lo que no es necesario volverlas a incluir dentro de tu archivo
war.
•runtime. Indica que la dependencia será necesaria durante la ejecución de tu
aplicación pero no al compilar.
•test. Indica que la dependencia sólo es necesaria para compilar y ejecutar
los tests del proyecto. Estas dependencias no serán incluidas en el artefacto
final.
•system. Igual a provided pero aquí debes especifciar el path de tu disco
duro al jar que contiene esta dependencia. Así evitas que Maven la busque en los
repositorios.
•import. Solo funciona en Maven 2.0.9 y superior. Permite importar otros
archivos pom para simular herencia múltiple ya que Maven solo permite heredar de un
solo archivo POM

NOTA: Lo que puse especificando la version de java. Es porque por defecto Maven usa
la 1.4 supuestamente. Entonces debo especificar cual quiero que use, sino no va a
encontrar los binarios de java.
¿Cómo saber el groupId y el artifactId de una librería?
La opción más simple es utilizar un buscador de repositorios maven. Algunos
de los existentes: •http://www.jarhalla.com•http://www.mvnrepository.com
•http://www.jarfinder.com •http://www.jarvana.com

NOTA: Dentro del elemento build El elemento buildFinalName, indica el nombre

que tendrá el binario del proyecto. Por default Maven usa como nombre el
artifactId + version + package extension.

Existe una versión especial llamada Snapshot. Esta versión denota a proyectos en
desarrollo, en constante cambio. Maven en estos casos siempre descargará la
nueva versión del repositorio. De esta forma tú puedes estar haciendo cambios
constantes a tus artefactos y Maven garantiza que aquellos que los usen, tendrán
la última versión sin necesidad de estar cambiando de número de versión.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Este es el tuto que lei, por las dudas:

http://static1.1.sqspcdn.com/static/f/923743/15025126/1320942755733/Tutorial_de_Mav
en_3_Erick_Camacho.pdf

Un español dice que Ant es un gestior de la configuracion

Docker->simil a JDK

Nexus->gestor de repositorios, sirve entre otras cosas para mantener controladas

las librerias de una empresa.
En este caso, al compilar o usar las librerías, Maven primero buscará en el
repositorio local, si no están ahí buscará en el Nexus y si no se irá a Maven
Central y las instalará en el Nexus.
Diriamos que Nexus acelera la compilacion de Maven. Ademas permite la separacion
del codigo(control de versiones), de las librerias(Nexus).

Jenkins facilita la integracion continua. Se hace el build varias veces al dia

automaticamente (compilacion,validacion,packaging). Asi podes saber que anda, que
no anda a cada momento. Jenkins es un SERVIDOR DE INTEGRACION CONTINUA.

Lista de plugins del core de Maven (en vez de llamar a Ant):

http://maven.apache.org/plugins/