Let the user choose a different JasperReports class
Description
Environment
Attachments
Activity
Thomas Bayen June 16, 2015 at 7:13 AM
Our new plugin had some issues in the actual trunk version. Some changes in the trunk over the last year make it impossible (again) to deinstall the old plugin. We thought again about the whole issue and now we think that it might be good to be able to use both plugins at the same time (to make the transition easier). The technical problem with that is that both plugins need to use one common interface class (JRViewerProvider) and one common JasperReports library. We solved that in the way that our new plugin uses these things from the old plugin. That works well and allows to mix both.
If we are later sure that our plugin is much better and we do not need the old one any more we can think about moving these both things either to the new plugin or to org.adempiere.base (or even to a new plugin of its own).
Markus Bozem February 7, 2015 at 4:05 PM
Is this Implementation complete?
http://wiki.idempiere.org/en/JasperReportsFreiBier describes that you can create a config key "JASPER_STARTER_CLASS".
But there is no reference to this config key in the source code!
If so, this issue shouldn´t be closed.
Thomas Bayen June 18, 2014 at 12:19 PM
I worked much on this issue and tried many ways. The main problem is that the iDempiere packages division uses split packages. You can read here why this is a bad idea: http://wiki.osgi.org/wiki/Split_Packages. The package org.compiere.report is exported from the bundle org.adempiere.base and also in the bundle org.adempiere.report.jasper. This is solved by using Require-Bundle (see the above link). But that means that there is a fixed dependency between the plugins.
If we want to be able to exchange the jasper plugin (and this is what OSGi is about, isn't it?) we should change the exported package. What I did is the following:
change the package of the (from org.adempiere.report.jasper exported) interface JRViewerProvider into an own package (org.adempiere.report.jasper).
Do not call the ReportStarter via the DefaultProcessFactory (this is a classloader-internal call from inside package org.adempiere.base that seems to work only because of the Require-Bundles trick)
instead create a IProcessFactory service to call the ReportStarter
decouple all places with references to the org.adempiere.report.jasper and org.adempiere.report.jasper.library bundles and instead use package imports
You can see my commit here: https://bitbucket.org/tbayen/idempiere/commits/02899f2ca18e264cb67138702c96b737e6fcd614
Please check it. I would like a good way to exchange the jasper plugins asap to give the community the possibility to try out my new plugin with some new ideas.
Thomas Bayen June 9, 2014 at 12:42 PM
I want to explain the issue I have with just exchanging the plugin: At the end of the report creation process the ReportStarter starts (depending on some circumstances) an Viewer to view the report to the user. This viewer can be part of different user interfaces (zk or swing) and resides in the zk or swing package. For that there is an OSGi Service using the interface org.compiere.report.JRViewerProvider. This interface is part of the plugin org.adempiere.report.jasper (which I want to deactivate). And this interface contains a parameter of type JasperPrint. This type is taken from the plugin org.adempiere.report.jasper.library. That is why there is a hard dependency between org.adempiere.ui.zk (which implements the viewer) and these both plugins.
The first idea was to create a whole new plugin in the trunk for just this service interface. But I want to avoid that.
The given patch seems to have still some issues. I am working on it.
Thomas Bayen June 8, 2014 at 9:35 PMEdited
During the refactoring of my JR plugin I found that it is still not easy to integrate. There are some dependencies that lead to a tight coupling between the org.adempiere.report.jasper plugin and other core modules. I broke up this dependencies in a way that allows me to deactivate the legacy jasper modules and activate my own.
I did this by not naming the plugin as an osgi dependency but only the imported package names. For some cases I had to introduce an eclipse-only classpath dependency on the project (not in the osgi declaration files). (The classes that are used this way have to exist in the new plugin too.) I feel this is the most un-intrusive way.
I did a commit here: https://bitbucket.org/tbayen/idempiere/commits/4214ac181ef961ff24f41ef158373db431666119
Details
Details
Assignee
Thomas BayenReporter
Thomas BayenComponents
Affects versions
Priority
Minor
I see some possible enhancements in the ReportStarter class of JasperReports. Especially the naming schema of subreports can be enhanced but at the end this possibly will break backward compatibility. I see three approaches to solve this:
Create a sysconfig parameter to change the now-static value of ProcessUtil.JASPER_STARTER_CLASS. This will not allow to use different implementations at the same time to slowly migrate.
Use a new plugin and replace the org.adempiere.report.jasper bundle. This will allow to change the implementation without touching core but it will also not allow to mix different implementations.
Using the className field in AD_Report to set a name for a ReportStarter replacement. This will break the possibility to start a process before doing the jasper report.
My favourite is the last approach. I do not think that the possibility to start a process just before a report is used by someone. And if someone needs business logic at this point he can overload one of the ReportStarter implementations to do that.
WDYT?