4Trabes Historias de una empresa en 100 metros cuadrados

El blog de Trabe Soluciones

Gestión de dependencias en aplicaciones Play!, versión inicial: Ant + Maven

| | Comentarios

Uno de los cambios derivados de nuestra migración a Play! como framework MVC para aplicaciones web Java, es el uso de Ant como gestor de builds. En Trabe utilizamos Maven habitualmente, ya que nuestros proyectos se adaptan bien a la estructura y ciclo de vida que marca esta herramienta, sin embargo, las aplicaciones Play! y sus módulos definen su propia estructura de directorios y utilizan Ant. Maven está muy bien cuando te ciñes a su estructura de proyecto, pero si haces algo distinto se hace necesario escribir descriptores gigantes y, francamente, el soporte Ant de Play está suficientemente bien como para aceptar el cambio.

Usar Ant en este contexto sólo tiene un problema: Ant no gestiona dependencias. Para solventarlo, como no tenía mucho tiempo para pensármelo, opté inicialmente por combinar Ant y Maven. Esta solución es aplicable a cualquier proyecto que utilice Ant como gestor de builds, no sólo a los proyectos Play!

Para gestionar las dependencias con Maven, lo primero es crear un POM con lo mínimo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
                             http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.4trabes</groupId>
    <artifactId>awesome</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>4Trabes awesome Play library</name>

    <dependencies>
       <dependency>
            <groupId>org.op4j</groupId>
            <artifactId>op4j</artifactId>
            <version>1.0</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <configuration>
                    <outputDirectory>lib/</outputDirectory>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Mínima información acerca del proyecto, nuestra lista de dependencias (sin preocuparse de los scopes) y, muy importante, la configuración del plugin de dependencias para que copie las librerías en el directorio lib (o en otro lado, a gusto del consumidor).

Ahora es cuestión de añadir a nuestro build.xml una tarea que invoque el goal copy-dependencies del plugin dependency de Maven:

1
2
3
4
5
6
7
<target name="deps">
    <exec executable="mvn">
        <arg value="-f"/>
        <arg value="deps.xml"/>
        <arg value="dependency:copy-dependencies"/>
    </exec>
</target>

Pan comido. Cada vez que ejecutemos ant deps se descargarán las librerías que no tengamos.

Si se trata de un proyecto Play!, es buena idea configurar el plugin de dependencias para que excluya las librerías que vienen de serie con el framework para evitar conflictos. Aquí os dejo las exclusiones para la versión 1.0.2.1 (creo que están todas).

1
2
3
4
5
6
7
8
9
10
<excludeArtifactIds>
    activation,antlr,backport-util-concurrent,bcprov-jdk15,c3p0,
    cglib-nodep,commons-beanutils,commons-codec,commons-fileupload,
    commons-httpclient,commons-lang,commons-logging,core,dom4j,
    ehcache,ejb3-persistence,ezmorph,filters,geronimo-servlet_2.5_spec,
    groovy-all,gson,hibernate,hibernate-core,
    hibernate-commons-annotations,hibernate-entitymanager,hsqldb,
    jamon,jaxen,jsr107cache,jta,junit,log4j,lucene-analyzers,
    lucene-core,mail,oval,snakeyaml,slf4j-api,slf4j-log4j12
</excludeArtifactIds>

Aunque esta solución es válida decidí investigar un poco más y finalmente decidí cambiar Maven2 por Ivy, que me parece más “natural”. Pero eso lo dejo para otro post.

Lo sentimos, pero los comentarios están cerrados

La leche. Vosotros volviendo a ant desde maven, y luego el dinosaurio soy yo… :-P

30/Apr/2010 Dani

@Dani no es un volver, es un convivir :). Si el “estándar” con Play! es usar Ant, se usa. Es una herramienta más y tampoco tiene mucho problema aparte de tener que escribir los scripts en XML, que es un poco farragoso. En cualquier caso los builds que tenemos que gestionar son sencillos así que no creo que la cosa se salga de madre.

Pues a mi pe parece una buena herramienta, solo hay que conocer bien sus limites y ventajas, recomiendo ver: http://4trabes.com/2007/10/9/pretty-urls-mediante-reescritura-en-aplicaciones-jee-j2ee-sin-depender-de-apache