MAVEN - RESOLUCION DE PROBLEMAS

Problemas que me he ido encontrando y como solucionarlos.

PROXY
Aunque tengas configurado un proxy para todo el sistema, maven no entiende eso. Hay que configurarlo de forma específica en su fichero /etc/maven2/setting.xml

ENCODING
Cuando intentas compilar desde una máquina linux, el código desarrollado en un windows, suele ocurrir, que los encodings utilizados son diferentes.
Esto suele acarrear que el compilador no reconozca algunos caracteres de los ficheros fuentes y por tanto sea incapaz de compilarlos.

Para resolver esto, podemos informar explícitamente en qué juego de caracteres están nuestras fuentes.

A mi me gusta hacerlo mediante variable de entorno, ya que es un caso muy común y si intento que el equipo de trabajo desarrolle en UTF-8, seguro que a alguno se le escapa.

MAVEN_OPTS=-Dfile.encoding=ISO-8859-1

Aunque esto se puede establecer desde la lína de comandos cuando lanzas el maven o incluso en el propio pom.xml

ARTEFACTOS EN REPOSITORIOS EXTERNOS
Es muy cotidiano encontrase con que para construir nuestros proyectos, no encontremos algunas dependencias, ya sean de librerías o de plugins.

Para esto debemos tener registrado el repositorio en el que se encuentran para que se los traiga a nuestro repositorio local en el primer acceso.

En estas URL's podemos hacer una búsqueda rápida de artefactos para saber de donde podemos obtenerlos.

http://mvnrepository.com/
http://www.mvnbrowser.com/index.html

MAVEN

En esta serie de entradas intentaremos tomar apuntes de los temas claves para comprender y usar MAVEN.

En esta entrada hablaremos de...

1. Plugins y Goals
2. LIFECYCLE
3. COORDENADAS
4. DEPENDENCIAS

Plugins y Goals
Una imagen vale más que mil palabras.
Efectivamente, podríamos decir que un plugin, es un conjunto de goals.

A nivel de línea de comandos, cuando podemos invocar un plugin y un goal de la siguiente forma:

mvn plugin:goal

Como por ejemplo cuando lanzamos:

mvn dependency:purgue-local-repository

En realidad lo que estamos haciendo es lanzar el goal purgue-local-repository del plugin dependency

Estos son algunos de los colorarios que podríamos arrojar sobre los GOALS

• El goal, es la unidad básica de trabajo en MAVEN.
• Un goal se puede ejecutar por si solo, o formar parte de un complejo proceso de construcción
• MAVEN no sabe compilar tu proyecto. Se descarga el plugin y ejecuta el goal correspondiente. Como tampoco sabe empaquetar tu proyecto en un JAR.

LIFECYCLE
mvn install no es un goal específico de un plugin. Se trata de una fase en un LIFECYCLE.

Un lifecycle, es una secuencia ordenada de fases o pasos que conforman la construcción de un proyecto.

Una fase de un lifecycle, puede tener ninguno o varios goals asociados.

Cuando invocamos MAVEN con una fase, maven ejecuta todas las fases precedentes a dicha fase en determinado lifecycle (se entiende que si no se configura o especifica un lifecycle, se establece uno por omisión), hasta llegar a la fase indicada en la linea de comando.

Por lo tanto cuando ejecutamos mvn install, ejecuta compile, test y package previamente.

Un gráfico de como se ejecutan los goals asociados a un lifecycle:




Ejecutar mvn install tendría el mismo resultado que ejecutar:

mvn resources:resources \
compiler:compile \
resources:testResources \
compiler:testCompile \
surefire:test \
jar:jar \
install:install 

En este ejemplo, especificaríamos el goal que deseamos usar.

COORDENADAS
Existen unos atributos a forma de coordenadas que permiten identificar un proyecto de forma unívoca.




Tal y como aparece en la imagen, podemos identificar las COORDENADAS de un proyecto en su pom.xml y la forma de hacer referencia única a dicho proyecto es la siguiente:

groupId:artifactId:packagin:version

Estos 4 parametros conforman lo que se llama ESPACIO MAVEN.

DEPENDENCIAS
Cuando creamos un proyecto maven, solo hay que indicar las dependencias directas de nuestro proyecto. Maven calcula las dependencias de estas dependencias.
Es decir, si necesitamos junit para testar nuestro proyecto, solo tenemos que indicar que depende de junit.
Las dependencias de junit, serán resueltas de forma automática.

Esto es lo que Maven denomina dependencias transitivas:

Las dependencias tiene un ámbito. Si indicamos que junit tiene el ámbito de test, no estará disponible para el goal compile.

En concreto el ámbito provided, indica que el contenedor de la aplicación (tomcat, weblogic...) proveerá dicha dependencia, no incluyendose dentro del empaquetado (war, ear...)

Esto puede ocasionar que un proyecto compile, y se empaquete, pero a la hora de desplegarse lance un error si dichas dependencias no están debidamente provistas (un típico ClassNotFoundException)

Fuente: manual de maven de SONATA