On Thu, 2012-04-05 at 09:08 +0200, Jürgen Schmidt wrote: > 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 ;-)
Ok For the MySQL connector and pdf filter however, use of a separate repository, a project at SF or GC, is not required or less so, is that correct? Thanks, //drew > > > > Juergen > > > > > > thanks, > > > > //drew > > > >> > >> Pedro. > >> > >> > > > > > >
