¡La versión 2.0 de Play ya está lista! Ayúdanos a traducir la documentación de la útlima versión y sigue nuestro progreso.
Manuales, tutoriales & referencias
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:
lib/
de su aplicación.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.
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
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.0Cuando 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
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.
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 -> *
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.
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
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.
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 -> *
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
.
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.
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.
Comentarios