How to implement bulk printing of documents?

[PRONZATO Cedric RD-BIZZ-GRE]

Mondrian (also part of Pentaho) is also LGPL.

Okay, I am sure that you have chose to not include LGPL projects for good reasons but that is not fun as you exit much project integration.

[quote="answer of Thomas Morgner, JFreeReport owner"]
> can you confirm me that the following sentence is wrong:
> "We can use, but can not include, libraries licensed with LGPL. The licensing quirk here is that we can write code that uses the libraries but can't include (distribute) the libraries themselves. This means that we have to have the build.xml files out of the box with exclusions for these source files. For each one we should document which jar files are needed, where they can be obtained, and which build.xml file(s) need to be changed to compile the Java files that depend on them."
>
> As far as I understand LGPL (with my small non layer english) we can integrate it in any project till we put the lgpl licence and a readme that tells where to grab the sources?
>

In my opinion, you are right. But that's an Apache thing - they are on
a religious crusade against the GPL and LGPL. If they interpret the
LGPL very strictly, they have to provide the sources of the LGPLed
projects along with a license text for these libraries. (§6a and §6b of
the LGPL).

Their reasoning that they can write code that uses the library but
cannot distribute the library seems strange. If everything fails,
make the integration a 3rd party module that links against OFBiz and
JFreeReport. This way they dont have to take responsibility for it,
if they dont want it. Apache has a long time history of distributing
3rd party stuff - even closed source. Just look at ANT for that
matter :)
[quote]

Okay, so if other apache projects does it, could we also do it? Perhaps we could make a distinction between libraries needed for OFBiz core and the remaining?
As §6 also mention a "one of" I wonder which case would be the best.

Cédric,

-----Message d'origine-----
De : Jacques Le Roux [mailto:[hidden email]]
Envoyé : mardi 13 février 2007 14:30
À : [hidden email]
Objet : Re: How to implement bulk printing of documents?



> +1 . Ofbiz does uses it. Atleast there is document for ofbiz+birt
>
> But pentalo is SIMPLY great except licenze

True, so sorry that it's not ASL2 compatible.

What about http://openi.sourceforge.net/ (licence MPL 1.1 : ASL2 compatible)

please see also http://docs.ofbiz.org/display/OFBIZ/Load+OpenI+%28Mondrian+Implementation%29+under+OFBiz
and https://issues.apache.org/jira/browse/OFBIZ-641

Jacques

> ----- Original Message -----
> From: "Raj Saini" <[hidden email]>
> To: <[hidden email]>
> Sent: Tuesday, February 13, 2007 3:39 AM
> Subject: Re: How to implement bulk printing of documents?
>
>
> > Eclipse BIRT can be a better choice. It is CPL and I think
> > compatible with Apache License. BIRT also have a WYSIWYG designer.
> >
> > Thanks,
> >
> > Raj
> > David E. Jones wrote:
> >>
> >> Yes, that's right, and a good point Jacques. We wouldn't be able to
> >> include the libraries, so this really couldn't realistically become
> >> the best practice tool for OFBiz.
> >>
> >> -David
> >>
> >>
> >> On Feb 13, 2007, at 3:51 AM, Jacques Le Roux wrote:
> >>
> >>>> Pentaho Reporting (JFreeReport) is in LGPL
> >>>
> >>> I'm afraid that some licence problems are ahead...
> >>>
> >>> Jacques
> >>>
> >>> ----- Original Message -----
> >>> From: "PRONZATO Cedric RD-BIZZ-GRE"
> >>> <[hidden email]>
> >>> To: <[hidden email]>
> >>> Sent: Tuesday, February 13, 2007 11:06 AM
> >>> Subject: RE: How to implement bulk printing of documents?
> >>>
> >>>
> >>>> David,
> >>>>
> >>>> I am happy and for sure I will not leave OFBiz without adding
> >>>> JFreeReport support or I am not a man!
> >>>>
> >>>> Cédric,
> >>>>
> >>>> -----Message d'origine-----
> >>>> De : David E. Jones [mailto:[hidden email]] Envoyé :
> >>>> mardi 13 février 2007 10:54 À : [hidden email] Objet : Re:
> >>>> How to implement bulk printing of documents?
> >>>>
> >>>>
> >>>> Cedric,
> >>>>
> >>>> I think in general most OFBiz users are not too happy with
> >>>> JasperReports, and we have pretty much decided against using it
> >>>> as the
> >>> best practice tool for reporting in OFBiz.
> >>>>
> >>>> If you'd be interested in working on an integration to easily use
> >>>> JFreeReport with OFBiz (ie a request handler and such to make
> >>> the reports available from within OFBiz webapps), and on creating
> >>> a couple of sample reports we could certainly include those and
> >>> start reviewing that as the best practice reporting tool.
> >>>>
> >>>> Actually, to some extent there is a best-practice tool now that
> >>>> you can create XSL:FO files very easily from OFBiz screen and
> >>>> form
> >>> widgets. These have a number of nice things about them, but we
> >>> still don't have a visual tool for creating them, which is
> >>> something a lot of people are looking for in a reporting solution.
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On Feb 13, 2007, at 2:40 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
> >>>>
> >>>>> Damn I saw that there is some JasperReports in OFBiz but it is
> >>>>> the enemy as I am involved in JFreeReport.
> >>>>>
> >>>>> Cédric,
> >>>>>
> >>>>> -----Message d'origine-----
> >>>>> De : PRONZATO Cedric RD-BIZZ [mailto:cedric.pronzato@orange-
> >>>>> ftgroup.com] Envoyé : mardi 13 février 2007 10:26 À :
> >>>>> [hidden email] Objet : RE: How to implement bulk printing
> >>>>> of documents?
> >>>>>
> >>>>> Hi Jacopo,
> >>>>>
> >>>>> I would told you the following things:
> >>>>>
> >>>>> - use a reporting framework and not something based on fop and
> >>>>> xsl which is realy power consuming not itext directly. I would
> >>>>> use Pentaho Reporting (aka JFreeReport
> >>>>> http://reporting.pentaho.org/) on which the new version will be
> >>>>> heavily multi-threaded and which support xml templates. PS: I am also involved in this project.
> >>>>> - I would not use the single document definition that is already
> >>>>> in OFBiz. It will restrict it so much later if you want to make
> >>>>> groups, ...
> >>>>>
> >>>>> Cédric,
> >>>>>
> >>>>> -----Message d'origine-----
> >>>>> De : Jacopo Cappellato [mailto:[hidden email]] Envoyé : mardi 13
> >>>>> février 2007 09:20 À : [hidden email] Objet : How to
> >>>>> implement bulk printing of documents?
> >>>>>
> >>>>> What is the best/easiest way (if possible) to implement the bulk
> >>>>> printing of a set of PDF reports that share the same template
> >>>>> (aka screen widget definition)?
> >>>>> For example, generate a big PDF with all the purchase orders in
> >>>>> the created approved status; the pdf can then be printed and so
> >>>>> that the purchase orders are sent by mail to the suppliers.
> >>>>>
> >>>>> Ideally I'd like to reuse the existing screen definition that
> >>>>> defines the single document and just iterate over it and put the
> >>>>> output into a single PDF file.
> >>>>>
> >>>>> Any hints/ideas on how to implement this?
> >>>>>
> >>>>> Another interesting option would be that of bulk sending by
> >>>>> email a set of documents (for example one email per supplier
> >>>>> with the attached purchase order), but this is not very
> >>>>> important for me at the moment, just one more wish in my list.
> >>>>>
> >>>>> Jacopo
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>

[Jacques Le Roux]

Cedric,

> Okay, so if other apache projects does it, could we also do it? Perhaps we could make a distinction between libraries needed for
OFBiz core and the remaining?
> As §6 also mention a "one of" I wonder which case would be the best.

I'm not sure if you are already aware of it so here we go. Shark is in the same licence case as Pentaho (end BTW is embeded in
Pentaho). You may have a look at how we currently deal with such thing (see OPTIONNAL_LIBRAIRIES)

About that point

> Their reasoning that they can write code that uses the library but
> cannot distribute the library seems strange.

Because in doing such way you are safe from the viral part of GPL/LGPL. IANAL but I guess it's the main reason.

I don't know about Ant : I care about OFBiz. For instance take a look at :
http://forums.openqa.org/thread.jspa?messageID=18362&#18362

Jacques

----- Original Message -----
From: "PRONZATO Cedric RD-BIZZ-GRE" <[hidden email]>
To: <[hidden email]>; "Jacques Le Roux" <[hidden email]>
Sent: Tuesday, February 13, 2007 3:10 PM
Subject: RE: How to implement bulk printing of documents?


> Mondrian (also part of Pentaho) is also LGPL.
>
> Okay, I am sure that you have chose to not include LGPL projects for good reasons but that is not fun as you exit much project
integration.
>
> [quote="answer of Thomas Morgner, JFreeReport owner"]
> > can you confirm me that the following sentence is wrong:
> > "We can use, but can not include, libraries licensed with LGPL. The licensing quirk here is that we can write code that uses the
libraries but can't include (distribute) the libraries themselves. This means that we have to have the build.xml files out of the
box with exclusions for these source files. For each one we should document which jar files are needed, where they can be obtained,
and which build.xml file(s) need to be changed to compile the Java files that depend on them."
> >
> > As far as I understand LGPL (with my small non layer english) we can integrate it in any project till we put the lgpl licence
and a readme that tells where to grab the sources?

> >
>
> In my opinion, you are right. But that's an Apache thing - they are on
> a religious crusade against the GPL and LGPL. If they interpret the
> LGPL very strictly, they have to provide the sources of the LGPLed
> projects along with a license text for these libraries. (§6a and §6b of
> the LGPL).
>
> Their reasoning that they can write code that uses the library but
> cannot distribute the library seems strange. If everything fails,
> make the integration a 3rd party module that links against OFBiz and
> JFreeReport. This way they dont have to take responsibility for it,
> if they dont want it. Apache has a long time history of distributing
> 3rd party stuff - even closed source. Just look at ANT for that
> matter :)
> [quote]
>
> Okay, so if other apache projects does it, could we also do it? Perhaps we could make a distinction between libraries needed for

OFBiz core and the remaining?

> As §6 also mention a "one of" I wonder which case would be the best.
>
> Cédric,
>
> -----Message d'origine-----
> De : Jacques Le Roux [mailto:[hidden email]]
> Envoyé : mardi 13 février 2007 14:30
> À : [hidden email]
> Objet : Re: How to implement bulk printing of documents?
>
>
>
> > +1 . Ofbiz does uses it. Atleast there is document for ofbiz+birt
> >
> > But pentalo is SIMPLY great except licenze
>
> True, so sorry that it's not ASL2 compatible.
>
> What about http://openi.sourceforge.net/ (licence MPL 1.1 : ASL2 compatible)
>
> please see also http://docs.ofbiz.org/display/OFBIZ/Load+OpenI+%28Mondrian+Implementation%29+under+OFBiz
> and https://issues.apache.org/jira/browse/OFBIZ-641
>
> Jacques
>
> > ----- Original Message -----
> > From: "Raj Saini" <[hidden email]>
> > To: <[hidden email]>
> > Sent: Tuesday, February 13, 2007 3:39 AM
> > Subject: Re: How to implement bulk printing of documents?
> >
> >
> > > Eclipse BIRT can be a better choice. It is CPL and I think
> > > compatible with Apache License. BIRT also have a WYSIWYG designer.
> > >
> > > Thanks,
> > >
> > > Raj
> > > David E. Jones wrote:
> > >>
> > >> Yes, that's right, and a good point Jacques. We wouldn't be able to
> > >> include the libraries, so this really couldn't realistically become
> > >> the best practice tool for OFBiz.
> > >>
> > >> -David
> > >>
> > >>
> > >> On Feb 13, 2007, at 3:51 AM, Jacques Le Roux wrote:
> > >>
> > >>>> Pentaho Reporting (JFreeReport) is in LGPL
> > >>>
> > >>> I'm afraid that some licence problems are ahead...
> > >>>
> > >>> Jacques
> > >>>
> > >>> ----- Original Message -----
> > >>> From: "PRONZATO Cedric RD-BIZZ-GRE"
> > >>> <[hidden email]>
> > >>> To: <[hidden email]>
> > >>> Sent: Tuesday, February 13, 2007 11:06 AM
> > >>> Subject: RE: How to implement bulk printing of documents?
> > >>>
> > >>>
> > >>>> David,
> > >>>>
> > >>>> I am happy and for sure I will not leave OFBiz without adding
> > >>>> JFreeReport support or I am not a man!
> > >>>>
> > >>>> Cédric,
> > >>>>
> > >>>> -----Message d'origine-----
> > >>>> De : David E. Jones [mailto:[hidden email]] Envoyé :
> > >>>> mardi 13 février 2007 10:54 À : [hidden email] Objet : Re:
> > >>>> How to implement bulk printing of documents?
> > >>>>
> > >>>>
> > >>>> Cedric,
> > >>>>
> > >>>> I think in general most OFBiz users are not too happy with
> > >>>> JasperReports, and we have pretty much decided against using it
> > >>>> as the
> > >>> best practice tool for reporting in OFBiz.
> > >>>>
> > >>>> If you'd be interested in working on an integration to easily use
> > >>>> JFreeReport with OFBiz (ie a request handler and such to make
> > >>> the reports available from within OFBiz webapps), and on creating
> > >>> a couple of sample reports we could certainly include those and
> > >>> start reviewing that as the best practice reporting tool.
> > >>>>
> > >>>> Actually, to some extent there is a best-practice tool now that
> > >>>> you can create XSL:FO files very easily from OFBiz screen and
> > >>>> form
> > >>> widgets. These have a number of nice things about them, but we
> > >>> still don't have a visual tool for creating them, which is
> > >>> something a lot of people are looking for in a reporting solution.
> > >>>>
> > >>>> -David
> > >>>>
> > >>>>
> > >>>> On Feb 13, 2007, at 2:40 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
> > >>>>
> > >>>>> Damn I saw that there is some JasperReports in OFBiz but it is
> > >>>>> the enemy as I am involved in JFreeReport.
> > >>>>>
> > >>>>> Cédric,
> > >>>>>
> > >>>>> -----Message d'origine-----
> > >>>>> De : PRONZATO Cedric RD-BIZZ [mailto:cedric.pronzato@orange-
> > >>>>> ftgroup.com] Envoyé : mardi 13 février 2007 10:26 À :
> > >>>>> [hidden email] Objet : RE: How to implement bulk printing
> > >>>>> of documents?
> > >>>>>
> > >>>>> Hi Jacopo,
> > >>>>>
> > >>>>> I would told you the following things:
> > >>>>>
> > >>>>> - use a reporting framework and not something based on fop and
> > >>>>> xsl which is realy power consuming not itext directly. I would
> > >>>>> use Pentaho Reporting (aka JFreeReport
> > >>>>> http://reporting.pentaho.org/) on which the new version will be
> > >>>>> heavily multi-threaded and which support xml templates. PS: I am also involved in this project.
> > >>>>> - I would not use the single document definition that is already
> > >>>>> in OFBiz. It will restrict it so much later if you want to make
> > >>>>> groups, ...
> > >>>>>
> > >>>>> Cédric,
> > >>>>>
> > >>>>> -----Message d'origine-----
> > >>>>> De : Jacopo Cappellato [mailto:[hidden email]] Envoyé : mardi 13
> > >>>>> février 2007 09:20 À : [hidden email] Objet : How to
> > >>>>> implement bulk printing of documents?
> > >>>>>
> > >>>>> What is the best/easiest way (if possible) to implement the bulk
> > >>>>> printing of a set of PDF reports that share the same template
> > >>>>> (aka screen widget definition)?
> > >>>>> For example, generate a big PDF with all the purchase orders in
> > >>>>> the created approved status; the pdf can then be printed and so
> > >>>>> that the purchase orders are sent by mail to the suppliers.
> > >>>>>
> > >>>>> Ideally I'd like to reuse the existing screen definition that
> > >>>>> defines the single document and just iterate over it and put the
> > >>>>> output into a single PDF file.
> > >>>>>
> > >>>>> Any hints/ideas on how to implement this?
> > >>>>>
> > >>>>> Another interesting option would be that of bulk sending by
> > >>>>> email a set of documents (for example one email per supplier
> > >>>>> with the attached purchase order), but this is not very
> > >>>>> important for me at the moment, just one more wish in my list.
> > >>>>>
> > >>>>> Jacopo
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> > >
> >
>

[David E Jones]

On Feb 13, 2007, at 3:46 AM, Jacopo Cappellato wrote:

> David E. Jones wrote:
>> You could even go a step further and call the service that  
>> generates the PDF asynchronously, and then have it call a service  
>> to print the PDF from the server (ie have the server connected to  
>> the printer, or accessing it over the network). Then as documents  
>> are ready they just go right to the printer.
>> -David
>
>
> What about implementing something more robust in this direction?
> I'm thinking of implementing document processor and distribution  
> features for the OFBiz framework.
> The idea is this:
>
> * when a user submits a report creation request (e.g. an invoice),  
> he has also to provide the distribution channel (file, mail, print,  
> fax, etc...) and also the physical device options (to and cc email  
> address, printer name, fax number etc...)
> * the request is stored in a record somewhere (a new entity or  
> something existing, in the Content component?, or just the  
> JobSandbox entity) with the following information:
>
> jobId|status|screen path|input context(serialized?)|output channel  
> (print/mail etc...)|output options (e.g. \\printserver\prt01, num  
> of copies etc..)
>
> * an async service listens to this entity and process the report  
> creation requests, then updates the status there
>
> For set of documents we could simply create many records in the  
> above entity.
>
> Does it make sense?

Yeah, I think so. Sounds interesting.

As far as my thoughts on which to go: rather than having job  
management just for this, it might be nice to use the service engine  
job management for it and just store parameters in the persisted  
context and such. The service engine job management is pretty feature  
rich on a low level, but it needs some enhancements to the management  
UI. That is actually of the areas that may see some work during the  
dev conference.

-David

[Jacopo Cappellato]

David E. Jones wrote:

>
> On Feb 13, 2007, at 3:46 AM, Jacopo Cappellato wrote:
>>
>> What about implementing something more robust in this direction?
>> I'm thinking of implementing document processor and distribution
>> features for the OFBiz framework.
>> The idea is this:
>>
>> * when a user submits a report creation request (e.g. an invoice), he
>> has also to provide the distribution channel (file, mail, print, fax,
>> etc...) and also the physical device options (to and cc email address,
>> printer name, fax number etc...)
>> * the request is stored in a record somewhere (a new entity or
>> something existing, in the Content component?, or just the JobSandbox
>> entity) with the following information:
>>
>> jobId|status|screen path|input context(serialized?)|output channel
>> (print/mail etc...)|output options (e.g. \\printserver\prt01, num of
>> copies etc..)
>>
>> * an async service listens to this entity and process the report
>> creation requests, then updates the status there
>>
>> For set of documents we could simply create many records in the above
>> entity.
>>
>> Does it make sense?
>
> Yeah, I think so. Sounds interesting.
>
> As far as my thoughts on which to go: rather than having job management
> just for this, it might be nice to use the service engine job management
> for it and just store parameters in the persisted context and such. The
> service engine job management is pretty feature rich on a low level, but
> it needs some enhancements to the management UI. That is actually of the
> areas that may see some work during the dev conference.
>
> -David
>

Ok, I will look into the details in this direction.

The next steps could be:

a) review the existing job scheduling services and entities (what is
missing or should be enhanced to properly support output management?)
b) ui: enhancements to the webtools
c) ui: implement a new screen in WorkEffort for "My Submitted Jobs"
where a user can see the job scheduled by him and maybe further filter
the list to see the one of 'type' output (aka documents)
d) create a generic service (similar to the one used to send emails),
that given a context, a printer name, and a screen name (the template
for the document) can be put in the job queue (async, thus visible in #b
and #c) and once executed will create a pdf and send it to the printer


Misc ideas:

A) if we store the persisted context in the JobSandbox, then the same
job can be re-run to recreate the document: the contaxt is passed to the
screen definition, the actions (minilang/bsh) are run and the context is
filled with data, that is then shown on screen by the widgets/fo templates
B) as an alternative option to #A, we could also give the ability to
store the persisted context AFTER the actions are run, so that, if we
rerun the job (aka recreate the document) the context is immediately
served to the widgets/fo templates: this would be a nice way to "store"
the documents (like invoices etc...); do you think it is possible/useful
something like this?

Anyone interested in this?
Ideas, remarks?

Jacopo