Cómo usar el control de versiones con JasperReports

Estamos a punto de comenzar el desarrollo de una serie de informes utilizando Jasper Server Reports versión 3.7.0 CE.

¿Alguien tiene alguna recomendación sobre cómo administrar mejor el control de versiones con este desarrollo, dado que la estructura de las unidades de informes se gestiona en la database y a través de iReport o la interfaz web?

De hecho, puede importar / exportar a una estructura de directory utilizando los scripts js-import / js-export, pero luego no puede editar estos files directamente con iReport .

¿Alguien tiene alguna indicación?

Si estuviera en su position, habría establecido este tipo de process:

  • fin de la session de desarrollo: exportar todos los informes a una estructura de directorys en un proyecto bajo control de versiones
  • comprometer el proyecto
  • antes de la siguiente session de desarrollo: sincronice el proyecto con el repository svn
  • importar la estructura del directory a Jasper Server Reports
  • continuar el desarrollo

Esto es problemático He establecido un repository de subversión para permitir la entrega de informes estándar, pero es un verdadero dolor porque jasper no lo hace ni un poco fácil.

Creé un proyecto maven con un descriptor de ensamblaje para que "src / main / xml / resources / Reports, adhoc, Domains, etc." se pueda empaquetar en un zip que se envía a nuestro repository maven.

El mayor problema es que no puedes simplemente desarrollar controles de input y input simplemente modificando los files XML. El desarrollador debe importar lo que está en control de fuente en un server jaspe en funcionamiento, modificar los informes o agregar nuevos (después de asegurarse de que su organización y orígenes de datos estén configurados) y una vez que esté satisfecho de que los informes funcionan, exporte los resources a un directory o file comprimido, modifique manualmente todas las references en los files exportados desde las fonts de datos y las ubicaciones de los resources específicos de la organización a "genérico" antes de verificar sus cambios.

Al importar a jaspe, el mismo process tiene que hacerse al revés. Los paths generics y los valores de la organización deben convertirse a la organización del desarrollador para que puedan importarse / actualizarse fácilmente y él puede probar que el "viaje networkingondo" completo funciona correctamente antes de registrarse.

Para facilitar la comprobación de exportaciones / subversiones, creé un file de compilation ant que vive en el directory raíz del proyecto maven. Las requestes de compilation (o leerán un file de properties) para determinar la location zip exportada, la id de la organización del tree exportado. Luego abre el file comprimido exportado de jasper, lo explota, realiza reemploops de text en los files, restablece los elementos "createdDate" y "updatedDate" a algo estándar (para que el desarrollador no termine revisando files que no han cambiado realmente) ya que jasper no conserva los valores de date), y luego copy los files en el tree de subversión.

Para el process de import (desde el tree de subversión a jasper) tenemos un script que toma como input el id de la organización y luego modifica los files xml versionados a los valores apropiados para que todo el tree pueda importarse / actualizarse fácilmente en su organización.

La razón por la cual se requiere este nivel de complejidad es para permitirnos crear los mismos informes estándar en un entorno de múltiples inquilinos, además la noción de jasper de implementar informes es absolutamente extraña. No estoy seguro de que sea posible dificultar este process si tuviera la intención de hacerlo.