Entornos de desarrollo virtuales #grails y #python

En Solocontrata.me desarrollamos nuestro frontend y middlend usando python y para el backend usamos grails. Como es de esperarse en un proyecto sencillo la cantidad de dependencias no es muuuy grande pero aun así con las constantes mejoras en las librerías y los cambios de versión puede llegarse a algo parecido al aborrecible Dependency Hell.

Sigue leyendo

Anuncios

Recursos estáticos en #grails

Cuando se necesita usar un recurso estático en una clase java generalmente se usa un llamado a getResource*:

Class.getResourceAsStream("/ruta/archivo") //null
ClassLoader.getResourceAsStream("/ruta/archivo") //null
ClassLoader.getResource("/ruta/archivo").openStream() //null
this.class.getResource("/ruta/archivo") //esta debería funcionar
Thread.currentThread().contextClassLoader.getResourceAsStream("/ruta/archivo") //debería funcionar

en grails nuestros recursos estáticos deben encontrarse en la ruta src/java para que se encuentren disponibles tanto para todos los entornos (incluidas pruebas unitarios), sin embargo, el uso de las alternativas anteriores no aprovecha la interfaz de Spring org.springframework.core.io.Resource que nos varias ventajas sobre la carga normal de recursos.

Para hacerlo existen varias formas, entre ellas:

ApplicationHolder.application.parentContext.getResource("classpath:$filePath") //deprecated desde 2.0
new UrlResource( StaticResourceLoader.getResource("/ruta/archivo")) //mi preferida

La última opcion hace uso de la clase StaticResourceLoader disponible desde la versión 1.2 de grails y tiene como ventajas extra el evitar usar clases deprecated y permitir ser usada en test unitarios sin tener que hacer ningun mock.

Acelerando la gestión de dependencias en #grails

Un asunto con el desarrollo de grails es la gestión de dependencias, cada vez que se ejecuta un comando (grails run-app, grails test-app, grails install-plugin xxx) el entorno verifica las dependencias (librerias, plugins, etc) declaradas para el proyecto.

En nuestros proyectos grails este periodo de tiempo tomaba de 30 a 90 segundos!!! lo cual es más que suficiente para permitir más que una leve distracción (a.k.a solo leo este articulo y listo…) así que optamos por instalar una instancia de Artifactory para tener un repositorio maven local que almacenara las dependencias sin tener que ir a hacer el chequeo a los repositorios centrales.

Eso bajó los tiempos a 10-12 segundos puesto que aún era necesario el uso del repositorio centralizado de plugins de grails que usaba (si, hasta marzo de 2012) Subversion.

Sin embargo, desde hace unos pocos días gracias JFrog los plugins se han migrado a un repositorio estándar y en nuestra instancia de Artifactory solo tuvimos que agregar un nuevo repositorio externo apuntando a http://grails.org/plugins para dejar unicamente configurados en los proyectos (BuildConfig.groovy) nuestro repositorio Artifactory:

repositories {
        /*grailsPlugins()
        grailsCentral()*/

        grailsHome()
        mavenLocal()
        mavenRepo "http://x.x.x.x:8081/artifactory/libs-release" 
        mavenRepo "http://x.x.x.x:8081/artifactory/plugins-release" 
        
        //
        /*mavenCentral()
        mavenRepo "http://snapshots.repository.codehaus.org"
        mavenRepo "http://repository.codehaus.org"
        mavenRepo "http://download.java.net/maven/2/"
        mavenRepo "http://repository.jboss.com/maven2/"*/
    }

Lo que nos permite bajar los tiempos de verificación de dependencias a 3-4 segundos!!!!. Gracias a Germán Franco por toda la ayuda en la instalación y gestión de servidores de Alephsa.

#grails y los plugins pegajosos

Hace algún tiempo empecé a trabajar en una aplicación usando grails 2.0.0.M4 luego de actualizarla a 2.0.0 cada vez que corria una tarea tipo test-app obtenía un mensaje como:

You currently already have a version of the plugin installed [svn-1.0.1]. Do you want to update to [svn-1.0.0.M1]? [y,n]

que es muy molesto (generalmente abandono la consola y se quedaba esperando a que respondiera) entonces, aun cuando busqué directamente el plugin y no lo encontré supuse que era un problema de dependencias transitivas, para comprobarlo solo es necesario usar el comando dependency-report que genera un html con las dependencias, en mi caso los plugins fixtures y resources dependían del svn, asi que procedí a instalar las versiones actualizadas, sin embargo, obtenía el mismo mensaje y ahora otro más:

You currently already have a version of the plugin installed [resources-1.1.1]. Do you want to update to [svn-1.1.6]? [y,n]

sucede que los plugins no sólo son declarados en el application.properties, también pueden ser declarados como dependencias en el BuildConfig.groovy (para poder cargarlos en el scope apropiado y evitar dependencias) así que la solución fue editar BuildConfig.groovy:

grails.project.dependency.resolution = {
...
 plugins {
        compile ":hibernate:$grailsVersion"
        compile ":jquery:1.6.1.1"
        compile ":resources:1.1.6"

        build ":tomcat:$grailsVersion"
        
        runtime (":fixtures:1.1") {
            excludes ":svn:1.0.0.M1"
        }
        
    }
}

y listo, quizás un clean y una actualización de dependencias sean necesarios después de modificar el BuildConfig.groovy del proyecto antes de

#netbeans, #grails y el classpath (I)

Desde hace algún tiempo (un par de meses) he intentado usar netbeans (siempre he sido amante de STS pero consume recursos de forma excesiva) para desarrollar en grails. Una de las cosas más molestas es el hecho de que netbeans no incluye en el classpath del proyecto las librerias declaradas como dependencias en config/BuildConfig.groovy. Para un proyecto en el que estamos trabajando actualmente necesito usar la excelente librería webharvest y una de mis frustraciones era la incapacidad de usar el autocompletado de clases, métodos y argumentos así que decidí pasar un buen tiempo buscando alternativas…y no encontré.

De tal forma que lo único que se me ocurrió (acepto sugerencias de formas mejores) fue adicionar un Java Platform (netbeans->tools->Java Platforms) para el proyecto específico añadiendo enlaces (sudo ln -s origen destino, en win2 son accesos directos) a los .jar que uso en el proyecto (en este caso webharvest, hamcrest y porque no…el propio groovy):

Luego en las propiedades del proyecto selecciono el Java Platform modificado:

y finalmente no aparecen como errores de classpath las dependencias de webharvest!!!.

#grails: select con optionValue a partir de múltiples atributos

Solo para recordarlo: en grails (gsp) para hacer un select con optionValue (el valor presentado en cada opción) a partir de varios atributos de la lista de opciones, es necesario introducir una expresión que se evaluará para cada item del origen de datos del select, quizaś con un par de lineas de código quede mas claro:

<g:select name ="roles" optionKey="id" optionValue="${{it.name + ' - ' + it.type}}" multiple="true" from="${roles}"
                            value="${user?.roles*.id}"/>

#grails #activiti #shiro v0.1

Se publicó la primer versión del plugin de integración de Activiti con Apache Shiro para Grails, en esta versión:

* Implementada inicialización de IdentityService con GroupManager y UserManager
* Implementado servicio de enlace de nombre de usuario en sesion
* Prueba de integración con Grails-Activiti VacationRequest

la documentación actual y descarga del plugin se encuentran en bitbucket.