How to use version control with JasperReports

Question

We are about to start developing several reports using Jasper Server Reports version 3.7.0 CE reports.

Does anyone have any recommendations on how best to manage versions with this development, given that the structure of the report blocks is managed in the database and through iReport or in the web interface?

In fact, you can import / export to the directory structure using js-import / js-export scripts, but then you cannot edit these files directly using iReport .

Does anyone have pointers?

Answer 1

If I were you, I would set up the following process:

• end of development session: export all reports to the directory structure in a versioned project
• complete the project
• before the next development session: synchronize the project with the svn repository
• Jasper Server Report Import Directory Structure
• continue development

Answer 2

This is problematic. I installed the subversion repository to allow standard report delivery, but this is a real pain because jasper does not even make it a little easy.

I created a maven project with an assembly descriptor to "src / main / xml / resources / Reports, adhoc, Domains, etc." could be packaged in a zip code that was ported to our maven repository.

The biggest problem is that you cannot just develop adhoc and input controls by simply modifying the XML files. The developer must import what is in the initial control to the working jasper server, change reports or add new ones (after his organization and data sources are configured), and as soon as he is satisfied that the report works, exports the resources to the directory or zip file, manually change all links in exported files from data sources and the location of specific resources of the organization to "generic" before checking for changes.

When importing into jasper, the same process should be performed in reverse order. The general paths and meanings of an organization must be transformed into a developer organization so that they can be easily imported / updated, and it can prove that the full “round trip” works correctly before checking.

To simplify the export / subversion check procedure, I created an ant build file, which is located in the root directory of the maven project. A build request (or will read the properties file) to determine the exported zip location, the organization identifier of the exported tree. Then he opens the exported zip file from jasper, explodes it, replaces the text in the files, resets the createdDate and updateDate elements to something standard (so that the developer does not finish checking files that have not really changed since jasper saves the date), and then copy the files to the subversion tree.

For the import process (from the subversion tree to jasper), we have a script that takes the organization identifier as input, and then changes the xml version files to the appropriate values ​​so that the whole tree can be easily imported / updated into their organization.

The reason this difficulty level is required is to allow us to create the same standard reports in a multi-tenant environment, and the lucid concept of report deployment is absolutely strange. I'm not sure that it would be possible to make this process more complicated if you intended to do so.