incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: [EXTENSIONS]Alternative for Report Builder?
Date Thu, 05 Apr 2012 07:08:14 GMT
On 4/5/12 9:01 AM, drew wrote:
> On Thu, 2012-04-05 at 01:48 -0500, Pedro Giffuni wrote:
>> On 04/05/12 00:59, drew wrote:
>>> ...
>>>>> No not really. The problem are the dependent libs as already pointed
out. There is no or no easy replacement for this external stuff that is license compatible.
Not nice and we would love to have alternatives ...
>>>>> If volunteers will provide an alternative implementation that would be
Apache compatible then we will continue the support and include it as bundled extensions.
>>>> The pdfimport could use pdfbox, however my understanding is that even with
>>>> a replacement the feature was not really complete without OCR
>>>> capabilities, (yes
>>>> tesseract) but well.. it involves real work(TM).
>>> Hi Pedro,
>>> Point taken - It is not that there are any known issues, or breakages,
>>> only that no person has taken the step of building and pushing to the
>>> group for testing - is that the most accurate understanding?
>> Yes, I think that we will eventually get to it when we find time to
>> think out of release mode. Most of the few things that we did
>> lose will need a new home, just like happened with dmake
>> (which is really crappy but was much more necessary than
>> Pentaho or pdfimport).
> right - and in the case of Report Builder it is not just that the
> designer is removed from the build, but updates (patches) in source
> files comprising the core application are excluded also - I think that
> is true, yes? Which I would take it then that in this specific
> extensions case it is not just building it for publishing on SF but to
> make it functional would require someone building what is then a
> derivative of the entire suite, that is how it appears to me, is that
> accurate do you think?

yes, someone would have to take the code and create a new extension 
project on SourceForge or GoogleCode. Eventually (when it is a clean 
extension) it can be built with the SDK only. But I think it was Java, 
so using the NetBeans and the API plugin for example could be one option 
to create an easy to built and to maintain project. I am guessing only 
right now ;-)


> thanks,
> //drew
>> Pedro.

View raw message