infoandorra.com

El control del ciclo de vida de un proyecto nuestro, básicamente lo podemos controlar vía los plugins que configuremos en nuestro pom.xml.

Algunos de los plugins que podemos usar en nuestro pom, nos pueden parecer a primera vista ambiguos, o no saber muy  bien cuando utilizar uno u otro. Aquí iré dejando algunas notas acerca de ellos, cuando piense que puedan ser de utilidad o clarificadoras.

maven-jar-plugin, maven-war-plugin: permite generar jars o jars. por si mismo, no incuye en el paquete resultante ninguna de las dependencias que hayamos definido en el pom.xml, ni aunque estas esten definidas como compile (la generación del paquete no tiene en cuenta que una dependencia sea compile o provided; en principio, ninguna será incorporada a no ser que se especifique específicamente, por ejemplo, usando maven-assembly-plugin).

maven-assembly-plugin: permite incluir dependencias definidas en el pom.xml al paquete real que generaremos con nuestro proyecto. Si se abusa de el y cada ejecutable peca de usar jar’s o otros recursos que otros paquetes también incorporan en su interior, corremos el riesgo de abusar del tamaño de los proyectos.

Ejemplo de utilización del plugin maven-assembly-plugin con la finalidad de que la compliación de nuestro proyecto incorpore dentro del jar resultante las diferentes dependencias que hayamos definido en el pom.xml del proyecto, de manera que el artefacto resultante sea del tipo “with-dependencies” (“con todo incorporado dentro”):

maven-shade-plugin: Ejemplo de utilización, con la finalidad de que la compilación de nuestro proyecto genere un jar ejecutable (otra opción sería mediante el manifest.mf directamente, pero eso ya no sería un planteamiento maven)(obsérvese el uso que se hace del transformer, para indicar que maven se deberá comportar como si en el manifest.mf constara la clase ad.am.proyectoX.Main como clase de “arranque” del proyecto)   :

Ejemplo de definición de una dependencia en el pom.xml de un proyecto:

Si no indicamos atributo scope (como en el caso anterior), maven interpreta por defecto que el scope es compile, por lo que adjunta los artefactos a nuestro proyecto en tiempo de compilación.

Un ejemplo de cuando podemos querer utilizar dependencias compile, puede ser una aplicación que queremos poder ejecutar autónomamente, que simplemente copiando/pegando el jar resultante de la compilación en cualquier máquina con java pueda funcionar.

Si no queremos que nuestro artefacto crezca embebiendo un exceso de otros artefactos, maven prevée el scope provided, que compilará sin incluir la dependencia en nuestro artefacto resultante, ya que supuestamente, en el sitio en que despleguemos el resultado de nuestra compilación, nuestro artefacto ya encontrará ese otro artefacto.

Un ejemplo de cuando podemos querer utilizar dependencias provided, puede ser una aplicación war que haga uso de unos drivers (jar) que ya tenemos desplegados en el servidor web en que correrá la aplicación.

Los servidores vienen típicamente con una serie de modules ya incorporados (eg: artefactos apache), que pueden ser utilizables desde una un proyecto nuestro que los referencie como provided. También realizar un despliegue típico de un proyecto nuestro, como ejb o jar en el servidor de aplicaciones y posteriormente desplegar otro proyecto nuestro que referencie con scope provided al primero.

Aquel que utiliza maven lo hace principalmente con dos objetivos. O bien gestionar las dependencias (etiquetas dependencies) que tiene nuestro proyecto hacia otros proyectos/artefactos de software, o bien gestionar el ciclo de vida de nuestro proyecto/artefacto (etiquetas plugin y otras). Para ambos usos, maven se basará en el pom.xml que espera que se halle en la raiz del proyecto. 

Un desarrollador puede trabajar con Maven tanto desde dentro como desde fuera de eclipse.
La mayoría de los ide’s de eclipse que podemos descargar desde la web oficial ya vienen con Maven. No obstante, si queremos trabajar desde fuera de eclipse con Maven
(lo que a veces esta bien para poder hacer scriptar con comandos Maven,
o para poder trabajar escapando del caprichoso comportamiento ocasional de eclipse),
puede ser interesante instalar también Maven de manera independiente en nuestro sistema.

Cuando instalamos Maven, bien sea como una pieza de software autónoma, como formando parte de Eclipse o algún otro ide, Maven, por defecto, conocerá el repositorio remoto estandar http://mvnrepository.com, como el repositorio local que se corresponde a la carpeta .m2 que la instalación habrá creado en alguna ruta del tipo C:\Users\Pepito\.m2

Si queremos obtener artefactos que no están disponibles en el repositorio estándar Maven, deberemos configurar nuestro acceso a url’s que publiquen otros catálogos/repositorios de artefactos (han de ser repositorios que estén accesibles bien a través de internet, bien a través de nuestra red interna). Dicha configuración la podemos hacer en el pom.xml, aunque resulta mas práctico hacerla en el settings.xml (ubicado en la raiz de la carpeta .m2. es decir, en la raíz de repositorio que utilizamos para desarrollar, compilar, o generar nuestros artefactos, en local), que se trata de un fichero de configuración de Maven que controla el comportamiento mas general de este, y es común a todos los proyectos con los que estemos trabajando en nuestro workspace.

Maven, conforme vamos trabajando con nuestros proyectos y definiendo dependencias en los pom.xml de los mismos, va manteniendo una sincronía del repositorio .m2 local con el/los repositorios remotos, de manera que en el .m2 podamos tener catalogados los artefactos que usamos habitualmente y así no tener dependencia absoluta de los repositorios remotos y de cortes en las comunicaciones para poder compilar y generar artefactos.