Administrando las dependencias

El sistema de administración de dependencias de Play, le permite expresar las dependencias externas de su aplicación en un único archivo dependencies.yml.

Una aplicación Play puede tener tres tipos de dependencias:

El propio framework Play, ya que una aplicación Play siempre depende del framework.
Cualquier librería Java, instalada como un archivo JAR en el directorio lib/ de su aplicación.
Un módulo Play (de hecho, un fragmento de una aplicación) instalado en el directorio modules/ de su aplicación.

Una vez que ha definido estas dependencias en el archivo conf/dependencies.yml de su aplicación, Play resolverá, descargará e instalará todas las dependencias requeridas.

El formato del archivo de dependencias

Una dependencia se define mediante una organización, un nombre, y un número de revisión. En el archivo dependencies.yml deberá escribirla de la siguiente manera:

organisation -> name revision

Entonces, por ejemplo para la versión 1.0 del Módulo PDF Play se expresaría así:

play -> pdf 1.0

A veces, el nombre de la organización coincide con el nombre de la dependencia, como en el caso de commons-lang:

commons-lang -> commons-lang 2.5

En este caso, puede omitir el nombre de la organización y dejar solamente la dependencia:

commons-lang 2.5

Revisiones dinámicas

Una revisión puede ser estática (1.2, por ejemplo) o dinámica. Una revisión dinámica expresa un rango de revisiones permitidas.

Por ejemplo:

[1.0,2.0] concuerda con todas las versiones mayores o iguales que 1.0 y menores o iguales que 2.0
[1.0,2.0[ concuerda con todas las versiones mayores o iguales que 1.0 y menores que 2.0
]1.0,2.0] concuerda con todas las versiones mayores que 1.0 y menores o iguales que 2.0
]1.0,2.0[ concuerda con todas las versiones mayores que 1.0 y menores que 2.0
[1.0,) concuerda con todas las versiones mayores o iguales que 1.0
]1.0,) concuerda con todas las versiones mayores que 1.0
(,2.0] concuerda con todas las versiones menores o iguales que 2.0
(,2.0[ * (,2.0[ concuerda con todas las versiones menores que 2.0

dependencies.yml

Cuando usted crea una nueva aplicación, el archivo dependencies.yml es creado automáticamente en el directorio conf/:

# Application dependencies
    
require:
    - play 1.2

La sección require muestra una lista de todas las dependencias necesarias para su aplicación. Aquí, la nueva aplicación solo depende de Play versión 1.2. Pero imaginemos que su aplicación necesita Google Guava; en tal caso tendríamos:

# Application dependencies
    
require:
    - play 1.2
    - com.google.guava -> guava r07

El comando ‘play dependencies’

Para pedirle a Play que resuelva, descargue e instale las nuevas dependencias, ejecute play dependencies:

$ play dependencies
~        _            _ 
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/   s
~
~ play! 1.2, http://www.playframework.org
~ framework ID is gbo
~
~ Resolving dependencies using ~/Documents/coco/conf/dependencies.yml,
~
~ 	com.google.guava->guava r07 (from mavenCentral)
~ 	com.google.code.findbugs->jsr305 1.3.7 (from mavenCentral)
~
~ Downloading required dependencies,
~
~ 	downloaded http://repo1.maven.org/maven2/com/google/guava/guava/r07/guava-r07.jar
~ 	downloaded http://repo1.maven.org/maven2/com/google/code/findbugs/jsr305/1.3.7/jsr305-1.3.7.jar
~
~ Installing resolved dependencies,
~
~ 	lib/guava-r07.jar
~ 	lib/jsr305-1.3.7.jar
~
~ Done!
~

Ahora Play ha descargado dos archivos JAR (guava-r07.jar, jsr305-1.3.7.jar) del repositorio dentral de Maven, y los ha instalado en el directorio lib/.

Pero, ¿Por qué dos JAR, si solo declaramos una dependencia? Porque Google Guava tiene una dependencia transitiva. En realidad, esta dependencia no es necesaria realmente y nos gustaría excluírla.

Dependencias transitivas

Las dependencias transitivas son agregadas por defecto. Pero existen varias maneras de excluírlas si es necesario.

1. Puede deshabilitar las dependencias transitivas para una dependencia en particular:

# Application dependencies
    
require:
    - play 1.2
    - com.google.guava -> guava r07:
        transitive: false

2. Puede deshabilitar las dependencias transitivas para el proyecto completo:

# Application dependencies
    
transitiveDependencies: false    
    
require:
    - play 1.2
    - com.google.guava -> guava r07

3. Puede excluir explícitamente una dependencia específica:

# Application dependencies
    
require:
    - play 1.2
    - com.google.guava -> guava r07:
        exclude:
            - com.google.code.findbugs -> *

Manteniendo los directorios lib/ y modules/ sincronizados

Ahora, si ejecuta nuevamente play dependencies, la dependencia findbugs será omitida:

$ play deps
~        _            _ 
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/   
~
~ play! 1.2, http://www.playframework.org
~ framework ID is gbo
~
~ Resolving dependencies using ~/Documents/coco/conf/dependencies.yml,
~
~ 	com.google.guava->guava r07 (from mavenCentral)
~
~ Installing resolved dependencies,
~
~ 	lib/guava-r07.jar
~
~ ********************************************************************
~ WARNING: Your lib/ and modules/ directories and not synced with 
~ current dependencies (use --sync to automatically delete them)
~
~ 	Unknown: ~/Documents/coco/lib/jsr305-1.3.7.jar
~ ********************************************************************
~
~ Done!
~

Sin emabargo, el archivo jsr305-1.3.7.jar descargado anteriormente, todavía está presente en el directorio lib/ de nuestra aplicación.

Para mantener los directorios lib/ y modules/ sincronizados con el sistema de administración de dependencias, puede agregar la opción --sync al comando dependencies:

play dependencies --sync

Si ejecuta el comando de nuevo, los archivos JAR ignorados serán eliminados.

Cuando pasa a producción una aplicación, puede reducir el tamaño de los módulos eliminando el códigos fuente y la documentación. Puede hacer ésto agregando la opción --forProd al comando:

play dependencies --forProd

Así eliminará los directorios documentation/, src/, tmp/, *sample*/ y *test*/ de cada módulo.

Resolución de conflictos

Cuando dos componentes necesitan diferentes revisiones de la misma dependencia, el administrador de conflictos deberá elegir alguno. Por defecto, se quedará con la revisión más actual e ignorará a las restantes.

Pero hay una excepción. Cuando una dependencia del núcleo del propio framework Play se encuentra en conflicto, la versión disponible en $PLAY/framework/lib será la preferida. Por ejemplo, Play depende de commons-lang 2.5 pero si tu aplicación requiere commons-lang 3.0:

# Application dependencies
    
require:
    - play 1.2
    - com.google.guava -> guava r07:
        transitive: false
    - commons-lang 3.0

Ejecutando play dependencies se ignorará commons-lang 3.0 aún siendo una versión más actual:

play dependencies
~        _            _ 
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/   
~
~ play! 1.2, http://www.playframework.org
~ framework ID is gbo
~
~ Resolving dependencies using ~/Documents/coco/conf/dependencies.yml,
~
~ 	com.google.guava->guava r07 (from mavenCentral)
~
~ Some dependencies have been evicted,
~
~	commons-lang 3.0 is overriden by commons-lang 2.5
~
~ Installing resolved dependencies,
~
~ 	lib/guava-r07.jar
~
~ Done!
~

Además, tenga en cuenta que las dependencias disponibles en $PLAY/framework/lib no serán instaladas en el directorio lib/ de tu aplicación.

Algunas veces deseará forzar una versión específica de una dependencia, ya sea para sobreescribir una dependencia del núcleo o para elegir una versión distinta a la última disponible.

En tal caso podrá especificar la opción force en cualquier dependencia:

# Application dependencies
    
require:
    - play 1.2
    - com.google.guava -> guava r07:
        transitive: false
    - commons-lang 3.0:
        force: true

Agregando nuevos repositorios

Por defecto, Play buscará las dependencias JAR en el Repositorio Central de Maven, y buscará Play modules en el Repositorio central de módulos Play.

Claro que también puedes especificar nuevos repositorios en la sección repositories:

# Application dependencies
    
require:
    - play 1.2
    - com.google.guava -> guava r07:
        transitive: false
    - commons-lang 3.0:
        force: true
    - com.zenexity -> sso 1.0
        
# Mis repositorios personalizados
repositories:
    
    - zenexity:
        type:       http
        artifact:   "http://www.zenexity.com/repo/[module]-[revision].[ext]"
        contains:
            - com.zenexity -> *

Utilizando esta configuración, todas las dependencias de la organización com.zenexity serán descargadas de un servidor HTTP remoto.

Repositorios Maven

También puede agregar repositorios compatibles con maven2 utilizando el tipo iBiblio así:

# Application dependencies
    
require:
    - play
    - play -> scala 0.8
    - org.jbpm -> jbpm-persistence-jpa 5.0.0:
        exclude:
            - javassist -> javassist *
            - org.hibernate -> hibernate-annotations *
            - javax.persistence -> persistence-api *
repositories:
    - jboss:
        type: iBiblio
        root: "http://repository.jboss.org/nexus/content/groups/public-jboss/"
        contains:
            - org.jbpm -> *
            - org.drools -> *

Repositorios locales

Finalmente y probablemente lo más importante, podríamos querer definir un repositorio que haga referencia a módulos locales. Con este escenario, las dependencias funcionan casi como la resolución de módulos del archivo application.conf (ahora obsoleta).

Entonces dada la siguiente estructura de carpetas,

myplayapp/
myfirstmodule/
mysecondmodule/

el siguiente archivo myplayapp/conf/depencencies.yml logrará nuestro objetivo.

# Application dependencies
    
require:
    - play
    - myfirstmodule -> myfirstmodule
    - mysecondmodule -> mysecondmodule
    
repositories:
    - My modules:
        type:       local
        artifact:   ${application.path}/../[module]
        contains:
            - myfirstmodule
            - mysecondmodule

Nota: No olvides ejecutar play dependencies myplayapp.

Configuración personalizada de Ivy

Internamente, Play utiliza Ivy para la resolución de dependencias. Si desea alguna configuración especial para un proxy o autenticación básica para acceder a un repositorio maven interno, puede editar el archivo ivysettings.xml que se encuentra en la carpeta .ivy2 en su directorio home.

Ejemplo 1, configurando Ivy para que ignore checksums:

<!-- .ivy2/ivysettings.xml -->
<ivysettings>
  <property name="ivy.checksums" value=""/>
</ivysettings>

Ejemplo 2, utilizar autenticación básica:

<!-- .ivy2/ivysettings.xml -->
<ivysettings>
  <credentials host="maven-repo.xxx" realm="Sonatype Nexus Repository Manager"
    username="user" passwd="reallygreatpassword"/>
</ivysettings>

Ejemplo 3, reutilizar el repositorio local maven y el repositorio manager:

<!-- .ivy2/ivysettings.xml -->
<ivy-settings>
  <!-- path to local maven repo and default maven layout -->
  <property name="local-maven2-pattern" 
    value="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[module]-[revision]" 
    override="false" />
 
  <!-- set resolver chain as default -->
  <settings defaultResolver="main" />
 
  <!-- configure caches -->
  <caches repositoryCacheDir="${user.home}/.ivy2/cache">
    <!-- do not cache from local .m2-->
    <cache name="nocache" useOrigin="true" />
    <cache name="default" />
  </caches>
 
  <resolvers>
    <chain name="main">
      <!-- as this is not cached, even changing SNAPSHOT dependencies 
        are resolved correctly -->
      <filesystem name="local-maven-2" m2compatible="true" local="true" 
        cache="nocache">
        <ivy pattern="${local-maven2-pattern}.pom" />
        <artifact pattern="${local-maven2-pattern}(-[classifier]).[ext]" />
      </filesystem>
      <!-- use repository manager as proxy to maven-central
        (and all other repositories)--> 
      <ibiblio name="repomanager" m2compatible="true"
        root="http://your.repomanager.intra/path/to/repo" cache="default"/>
    </chain>
  </resolvers>
</ivy-settings>

Hay varias cosas que puedes configurar: chequea la Documentación de configuración de Ivy.

Limpiando la caché de Ivy

La caché de Ivy puede volverse corrupta, especialmente cuando utilizamos el tipo http en la sección de repositorios de conf/dependencies.yml. Si esto sucede, y la resolución de dependencias no funciona, puede limpiar la caché con la opción --clearcache.

$ play dependencies --clearcache

Esto es quivalente a rm -r ~/.ivy2/cache.

Próximos pasos

Siguiente: Evolución de las bases de datos.

Playframework

Consulte

Contenidos

Elija la versión

Buscar

Libros