I am looking to simplify the deployment of the BIRT runtime, and currently what I have as a proof of concept is bundling the runtime into a custom module and deploying it at module load, which did not work as expected (due to OpenMRS module loading order issues).
So I wanted to find out if the following considerations make sense before I spend some time trying to get them to work:
Bundle Runtime folder into the resources folder in the omod as the using the name “birt-runtime-3_2_0” for Birt Runtime version 3.2.0
Add a separate working folder (suggested name birt-working) with the following: reports, datasets, logs, outputs (matching the configurations)
In the Module Activator: copy the working and runtime folders to the APPLICATION_DATA_DIRECTORY, then set the default global properties to the directories in the working folder, that can be changed later if needed
This would provide a starting environment out of the box.
Looking forward to hearing your thoughts, and comments
Sorry for the delayed response. I haven’t done any development on this module since ~2010 so you might need to ask one of the current contributors (e.g. @mseaton) for their thoughts.
I always wanted to have the runtime installed with the module, but the issue back then was the size of the OMOD (it was already over 100MB without including the runtime). I wasn’t around when we moved to Maven but always figured this would be pretty easy (i.e. specify a dependency on the BIRT runtime and it would pull it down when building the OMOD). Or in a perfect world it would download the dependency at deployment/runtime, but I don’t think that’s even a possibility with Maven.
I was under the impression that you could specify the order in which modules are loaded, but I haven’t been able to find a reference to any documentation covering that. You should at least be able to specify a dependency from the BIRT Module to a newly created BIRT Runtime Module, no?
I think it’s worth trying what you have outlined, but I would have figured it would be easier than that at this point. I’ve copied Mike Seaton in case he has any additional thoughts.
Thankfully, another developer disabled that behavior by default. But you should be able to set a runtime property (birt.alwaysUseOpenmrsJdbcProperties) that overrides the default url/username/password in the report design. Unfortunately, it’s either all or nothing (i.e. all reports use the overridden properties or they use their own). It would be nice to be able to specify that as a report-level property.
Here’s the code that was introduced that illustrates how the JDBC properties are overridden if the birt.alwaysUseOpenmrsJdbcProperties property is set to true.
I’m afraid I don’t have much more to offer. What you are suggesting
(building a custom module that installs BIRT runtime) should be feasible
what issues are you hitting?
Most of the brain power I have devoted to this topic recently has been
in trying to replace the need of the BIRT module by implementing the
same functionality via a Report Renderer in the reporting module. There
is a ticket for this here, which is pretty light on content:
https://issues.openmrs.org/browse/REPORT-251. I did a spike on this a
few years ago and ran into some issues I couldn’t overcome - I’m
struggling to find my documentation of that at the moment. It might be
ripe for another go.