You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Pedro Giffuni <pf...@apache.org> on 2011/11/02 15:18:06 UTC
Report Builder extension (was Re: [proposal] development for the first AOO release)
Hi Oliver;
What do you mean by "removal of the 3rd party components"?
I think the report builder should be moved to Apache-extras
with three suggestions:
- Attempt to contact the authors of the pentaho stuff,
maybe they would like to have a say in it's future or
even relicense it.
-Wait until the headers are changed to AL2, before moving
it out.
- Rob has a SVN dump: maybe we can use it to preserve most
of the early history of the stuff we move to Apache-extras.
cheers,
Pedro.
--- On Wed, 11/2/11, Oliver-Rainer Wittmann <or...@googlemail.com> wrote:
...
>
> I will start working on the removal of all 3rd party
> components which
> are needed for the report builder extension.
>
> Best regards, Oliver.
>
>
> On 24.10.2011 15:18, Oliver-Rainer Wittmann wrote:
> > Hi,
> >
> > I would like to propose the following development
> milestones on our way
> > to the first AOO release:
> >
> > - "IP cleared" milestone
> > For this milestone we should remove all 3rd party
> components which are
> > not compliant to Apache's "Third-Party Licensing
> Policy" [1]. All
> > license headers in the source code files should be
> updated according to
> > Oracle's SGA. Additionally, we may update certain
> information in the
> > product in order to reflect that the product is now
> coming from Apache
> > (e.g. the splash screen, the about dialog, ...).
> > Then the IP review required by Apache could be
> performed in order to
> > meet the corresponding requirements for our first
> release.
> > This milestone would result in an OpenOffice.org
> missing a lot of
> > important features, but this milestone would be the
> basis regarding
> > Apache's IP rules. This milestone could be released
> according to the
> > Apache rules.
> >
> > - "features back" milestone
> > For this milestone we should work on bringing back the
> features which
> > are lost in the previous milestone. I do not think
> that we have to bring
> > back every feature for a first release. Thus, we would
> have got the
> > possibility to work on the features which are of most
> interest. At some
> > point we could create a "release candidate" and start
> working on
> > stabilizing it for a first release, if we think that
> the "must have"
> > features are back.
> >
> >
> > In order to coordinate efforts and to avoid duplicate
> work I propose to
> > use the IP clearance wiki page [2].
> > The basis for its content is more or less the Apache
> Migration wiki page
> > [3]. Some additional information has been collected on
> certain 3rd party
> > components. Also priorities have been assigned. But
> its content is not
> > "nailed in stone". It currently reflects more or less
> the input and
> > opionions of the editing contributors to these IP
> clearance issues.
> > Thus, it would be a living document to reflect our
> knowlegde about these
> > IP clearance issues. It would also document our
> efforts and our
> > decisions regarding these efforts.
> >
> >
> > Any remarks/comments/improvements/adjustments?
> > Any objections to follow such plan for our first
> release?
> >
> >
> > Best regards, Oliver.
> >
> > P.S.: I will be out-of-office for the rest of the
> week. Thus, I will
> > probably not reply to your input regarding my proposal
> this week -
> > please excuse.
> >
> > References:
> > [1] http://www.apache.org/legal/3party.html
> > [2] https://cwiki.apache.org/confluence/display/OOOUSERS/IP_Clearance
> > [3] http://ooo-wiki.apache.org/wiki/ApacheMigration
>
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 07.11.2011 10:23, Reizinger Zoltán wrote:
> This means, that the build under windows needs source jfreereport,
> hosted in apache extras or other places?
Please see my reply to Oliver: we always used pre-built jars on all
platforms.
Regards,
Mathias
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Reizinger Zoltán <zr...@hdsnet.hu>.
2011.11.07. 10:05 keltezéssel, Oliver-Rainer Wittmann írta:
> Hi,
>
> On 05.11.2011 12:09, Ariel Constenla-Haile wrote:
>> Hello Oliver,
>>
>> On Wed, Nov 02, 2011 at 03:52:05PM +0100, Oliver-Rainer Wittmann wrote:
>>> I am not planning to remove the report builder extension.
>>> I am planning to remove the 3rd party components which are used by
>>> the report builder extension as they are licensed under LGPL.
>>> This will have the effect that the report builder will not work
>>> anymore. Thus, I have got in mind to disable its building without
>>> touching any code of it.
>>
>> will you also disable building the report builder with the system's
>> jars?
>>
>> If yes, then you should also remove the --enable-report-buider option
>> from configure.
>> Now, if you pass this switch to configure, the build breaks in all the
>> dirs. where the makefile.mk tries to include
>> $(SOLARBINDIR)/jfreereport_version.mk
>>
>> reportbuilder/java/com/sun/star/report/util/
>> reportbuilder/java/com/sun/star/report/function/metadata/
>> reportbuilder/util/
>> reportbuilder/java/com/sun/star/report/pentaho/
>>
>> jfreereport_version.mk was a copy of jfreereport/version.mk that no
>> longer exists
>> http://svn.services.openoffice.org/opengrok/xref/OOO340_m0/jfreereport/prj/d.lst#2
>>
>>
>>
>
> As you have seen, I was trying to keep the report builder extension
> buildable with the system's jars.
> Unfortunately, I did not test such a build. I was assuming that a
> former build with the configure options --enable-report-builder
> --with-system-jfreereport works out of the box.
>
> Thus, I will try to make such a build possible.
This means, that the build under windows needs source jfreereport,
hosted in apache extras or other places?
Zoltan
>
>
> Best regards, Oliver.
>
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 05.11.2011 12:09, Ariel Constenla-Haile wrote:
> Hello Oliver,
>
> On Wed, Nov 02, 2011 at 03:52:05PM +0100, Oliver-Rainer Wittmann wrote:
>> I am not planning to remove the report builder extension.
>> I am planning to remove the 3rd party components which are used by
>> the report builder extension as they are licensed under LGPL.
>> This will have the effect that the report builder will not work
>> anymore. Thus, I have got in mind to disable its building without
>> touching any code of it.
>
> will you also disable building the report builder with the system's
> jars?
>
> If yes, then you should also remove the --enable-report-buider option
> from configure.
> Now, if you pass this switch to configure, the build breaks in all the
> dirs. where the makefile.mk tries to include
> $(SOLARBINDIR)/jfreereport_version.mk
>
> reportbuilder/java/com/sun/star/report/util/
> reportbuilder/java/com/sun/star/report/function/metadata/
> reportbuilder/util/
> reportbuilder/java/com/sun/star/report/pentaho/
>
> jfreereport_version.mk was a copy of jfreereport/version.mk that no
> longer exists
> http://svn.services.openoffice.org/opengrok/xref/OOO340_m0/jfreereport/prj/d.lst#2
>
>
As you have seen, I was trying to keep the report builder extension
buildable with the system's jars.
Unfortunately, I did not test such a build. I was assuming that a former
build with the configure options --enable-report-builder
--with-system-jfreereport works out of the box.
Thus, I will try to make such a build possible.
Best regards, Oliver.
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Alexander Thurgood <al...@gmail.com>.
Le 05/11/11 12:09, Ariel Constenla-Haile a écrit :
Hi all,
> If yes, then you should also remove the --enable-report-buider option
> from configure.
> Now, if you pass this switch to configure, the build breaks in all the
> dirs. where the makefile.mk tries to include
> $(SOLARBINDIR)/jfreereport_version.mk
>
Absolutely, if the jars aren't there, that build switch will cause the
build to fail. Alternatively, you could change all of the mk files to
point to....nowhere, or just silently drop and return, but then what
would be the point of having the switch ?
This is a sizeable chunk of code/functionality that is being removed
here btw, especially for all of those who use databases. And for the
doubting Thomases who might be inclined to think that using OOo with
databases was a minority affair, they might wish to look up the stats on
the migrated user forums as to how many people ask questions about
database usage. It is far from insignificant.
Alex
Re: Report Builder extension (was Re: [proposal] development for the
first AOO release)
Posted by Ariel Constenla-Haile <ar...@gmail.com>.
Hello Oliver,
On Wed, Nov 02, 2011 at 03:52:05PM +0100, Oliver-Rainer Wittmann wrote:
> I am not planning to remove the report builder extension.
> I am planning to remove the 3rd party components which are used by
> the report builder extension as they are licensed under LGPL.
> This will have the effect that the report builder will not work
> anymore. Thus, I have got in mind to disable its building without
> touching any code of it.
will you also disable building the report builder with the system's
jars?
If yes, then you should also remove the --enable-report-buider option
from configure.
Now, if you pass this switch to configure, the build breaks in all the
dirs. where the makefile.mk tries to include
$(SOLARBINDIR)/jfreereport_version.mk
reportbuilder/java/com/sun/star/report/util/
reportbuilder/java/com/sun/star/report/function/metadata/
reportbuilder/util/
reportbuilder/java/com/sun/star/report/pentaho/
jfreereport_version.mk was a copy of jfreereport/version.mk that no
longer exists
http://svn.services.openoffice.org/opengrok/xref/OOO340_m0/jfreereport/prj/d.lst#2
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 11/10/11 5:00 PM, Alexander Thurgood wrote:
> Le 10/11/11 16:16, Pedro Giffuni a écrit :
>
> Hi Pedro, Ariel,
>
> Oh I understand perfectly well why it is being done in this way, I make
> my living out of intellectual property so I would be the first one to
> say "IP clearance takes precedence" in line with the rules that Apache has.
>
> I also understand that it could still continue to be built separately,
> for those who have the time, energy and will to correct the inevitable
> bitrot build errors that will creep in over time because code has
> changed elsewhere, but no one thought to bother about adapting those
> code changes to keep this module buildable. In other words, it will
> become harder to build and maintain over time because it has been dropped.
>
> Nonetheless, even if one looks on the optimistic side, there still
> remain a few questions :
>
> (1) who in all honesty will do it ?
> - if any of the Linux distribs are interested, they will package it
> with their own build of AOOo (assuming that some of them switch from
> LibreOffice to AOOo or just continue to provide both)
it always a question of who will do it. That's open source, if somebody
feels it is important, takes the responsibility for it and just do it
then it's fine for all if the work is contributed back. But you need
always somebody who take care of it.
Wishes alone doesn't help here. And more general especially companies
who simply use open source software and never contribute anything back
should think about it.
>
> - what about distrib independent versions - obviously, there will be
> none from within AOOo itself, since it can not, so quo vadis ?
are you sure? Everybody can take the Apache source code and can provide
a binary and can bundle some further stuff with this package and call it
"MyPersonalRequirementsSatisfying Office". I think that is perfectly
fine as long as the bugs for the additional code are filtered correctly.
I am sure we will see a binary version of a pure Apache OpenOffice and
this will grow over time and will contain useful features that are more
important or more useful for many users than for example a lost filter
because of the license. And even dropped features can be put back if
somebody takes care of it and provide it as an extension. But again it's
always the same somebody have to take care of it.
>
> - what about Mac ?
> - what about Windows ?
>
mmh, i think that is on the plan. On Windows are probably more than 80%
of our users.
> I think that realistically, resources are spread too thinly on the
> ground for this to happen at present.
help is always welcome
>
>
> (2) what kind of message does this convey to Joe Public ?
> - AOOo (aka OOo) is destined only for those who know how to build and code ?
>
no, but we have to do some work at the beginning and the plan is to
provide replacements for all critical temporary dropped features.
> Somehow, I don't think that you'll hit your target audience with such an
> approach - a binary version that misses bits of what has become
> essential functionality for many will not sway people to switch from OOo
> to AOOo - in fact, it might well even make them switch to competing
> products.
i agree in some points but as i mentioned earlier our goal is to replace
all important missing pieces over time. Most of the temporary dropped
features are probably not important for many people. But sure some users
will miss something.
Juergen
>
>
> Perhaps someone will find a way of furthering the development of the
> original report designer instead, because that at least does form part
> of the SGA (it was already in the initial release of the OOo code all
> those years ago). I hope so, I really do.
>
>
>
> Alex
>
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Alexander Thurgood <al...@gmail.com>.
Le 10/11/11 16:16, Pedro Giffuni a écrit :
Hi Pedro, Ariel,
Oh I understand perfectly well why it is being done in this way, I make
my living out of intellectual property so I would be the first one to
say "IP clearance takes precedence" in line with the rules that Apache has.
I also understand that it could still continue to be built separately,
for those who have the time, energy and will to correct the inevitable
bitrot build errors that will creep in over time because code has
changed elsewhere, but no one thought to bother about adapting those
code changes to keep this module buildable. In other words, it will
become harder to build and maintain over time because it has been dropped.
Nonetheless, even if one looks on the optimistic side, there still
remain a few questions :
(1) who in all honesty will do it ?
- if any of the Linux distribs are interested, they will package it
with their own build of AOOo (assuming that some of them switch from
LibreOffice to AOOo or just continue to provide both)
- what about distrib independent versions - obviously, there will be
none from within AOOo itself, since it can not, so quo vadis ?
- what about Mac ?
- what about Windows ?
I think that realistically, resources are spread too thinly on the
ground for this to happen at present.
(2) what kind of message does this convey to Joe Public ?
- AOOo (aka OOo) is destined only for those who know how to build and code ?
Somehow, I don't think that you'll hit your target audience with such an
approach - a binary version that misses bits of what has become
essential functionality for many will not sway people to switch from OOo
to AOOo - in fact, it might well even make them switch to competing
products.
Perhaps someone will find a way of furthering the development of the
original report designer instead, because that at least does form part
of the SGA (it was already in the initial release of the OOo code all
those years ago). I hope so, I really do.
Alex
Re: Report Builder extension (was Re: [proposal] development for the
first AOO release)
Posted by Ariel Constenla-Haile <ar...@gmail.com>.
Hello Reizinger, *,
On Thu, Nov 10, 2011 at 12:47 PM, Reizinger Zoltán <zr...@hdsnet.hu> wrote:
> Hi Pedro,
>
> The report builder extension has 49 open bugs:
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=runnamed;namedcmd=SRB_open;list_id=2823
that link didn't work (may be a named saved search?). This may work:
https://issues.apache.org/ooo/buglist.cgi?bug_status=UNCONFIRMED;bug_status=NEW;bug_status=STARTED;bug_status=REOPENED;component=SRB
>> We can keep the sources, and maybe even some SVN history,
>> in Apache-extras but once it builds I don't think we have
>> to do a lot of maintenance.
it actually does. It's not simply an extension. This and the other
module, reportdesign,
require a maintainer with a deep knowledge of OOo core.
Regards
------------
Ariel Constenla-Haile
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Reizinger Zoltán <zr...@hdsnet.hu>.
Hi Pedro,
The report builder extension has 49 open bugs:
https://issues.apache.org/ooo/buglist.cgi?cmdtype=runnamed;namedcmd=SRB_open;list_id=2823
Lot of bugs reported by me, I was the volunteer QA on this feature.
Some of them needs to be repaired, and some features available in
pentaho reporting, not implemented it in, for example subreports, and
new chart features from OOo.
If I know correctly the original developer will not continue working on it.
If some developer continue the development, I will do QA on it.
Regards,
Zoltan
2011.11.10. 16:22 keltezéssel, Pedro Giffuni írta:
> Hi Ariel;
>
> I honestly have no idea how this works: can we turn this
> into an uno extension, and make it available in the
> extensions site?
>
> We can keep the sources, and maybe even some SVN history,
> in Apache-extras but once it builds I don't think we have
> to do a lot of maintenance.
>
> Pedro.
>
> --- On Thu, 11/10/11, Ariel Constenla-Haile wrote:
>
>> the reportbuilder won't be built nor released by AOOo, but
>> anyone can
>> take the sources and build it (for example, it would be
>> useful to take
>> the sources and make a Netbeans project out of it).
>> This extension is not really extension in the real sense of
>> the term
>> (extending OOo without touching any line of source code),
>> it depends on
>> the core functionality introduced in the reportdesign
>> module.
>> AOOo is not removing reportdesign nor reportbuilder.
>>
>> The main issue is not the source code (on the software
>> grant from
>> Oracle, so no issue at all), nor the 3rd parties libraries
>> (the code
>> that relies on them can be built as an extension by anyone
>> who wants),
>> but the lack of man power with the knowledge to maintain
>> and further
>> develop it.
>>
>> Regards
>> --
>> Ariel Constenla-Haile
>> La Plata, Argentina
>>
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Mathias Bauer <Ma...@gmx.net>.
Am 10.11.2011 20:09, schrieb Pedro Giffuni:
>
>
> --- On Thu, 11/10/11, Mathias Bauer <Ma...@gmx.net> wrote:
> ...
>> Am 10.11.2011 16:22, schrieb Pedro Giffuni:
>>
>> > Hi Ariel;
>> >
>> > I honestly have no idea how this works: can we turn
>> this
>> > into an uno extension, and make it available in the
>> > extensions site?
>>
>> The report build *is* an extension.
>>
>
> Can this be built standalone and made available
> in the extensions site?
AFAIK nobody tried until now. You will need at least an OOo SDK plus the
jFreeReport jar files, maybe some jar files more.
Regards,
Mathias
Re: Report Builder extension (was Re: [proposal] development for the first AOO release)
Posted by Pedro Giffuni <pf...@apache.org>.
--- On Thu, 11/10/11, Mathias Bauer <Ma...@gmx.net> wrote:
...
> Am 10.11.2011 16:22, schrieb Pedro Giffuni:
>
> > Hi Ariel;
> >
> > I honestly have no idea how this works: can we turn
> this
> > into an uno extension, and make it available in the
> > extensions site?
>
> The report build *is* an extension.
>
Can this be built standalone and made available
in the extensions site?
> Or are you talking about the jfree jars alone? I'm afraid
> that they are not used via UNO but plain Java APIs, so
> there is no chance.
>
That's not a problem we just put them in SVN at Apache
Extras and bundle them with the extension.
The main code will be AL2 but all the requirements
maintain the original license, we don't have limitations
there.
FWIW, there are many OOo extensions maintained in google
code already:
http://code.google.com/hosting/search?q=openoffice.org&btn=Search+projects
cheers,
Pedro.
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Mathias Bauer <Ma...@gmx.net>.
Am 10.11.2011 16:22, schrieb Pedro Giffuni:
> Hi Ariel;
>
> I honestly have no idea how this works: can we turn this
> into an uno extension, and make it available in the
> extensions site?
The report build *is* an extension.
Or are you talking about the jfree jars alone? I'm afraid that they are
not used via UNO but plain Java APIs, so there is no chance.
Regards,
Mathias
Re: Report Builder extension (was Re: [proposal] development for the first AOO release)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Ariel;
I honestly have no idea how this works: can we turn this
into an uno extension, and make it available in the
extensions site?
We can keep the sources, and maybe even some SVN history,
in Apache-extras but once it builds I don't think we have
to do a lot of maintenance.
Pedro.
--- On Thu, 11/10/11, Ariel Constenla-Haile wrote:
>
> the reportbuilder won't be built nor released by AOOo, but
> anyone can
> take the sources and build it (for example, it would be
> useful to take
> the sources and make a Netbeans project out of it).
> This extension is not really extension in the real sense of
> the term
> (extending OOo without touching any line of source code),
> it depends on
> the core functionality introduced in the reportdesign
> module.
> AOOo is not removing reportdesign nor reportbuilder.
>
> The main issue is not the source code (on the software
> grant from
> Oracle, so no issue at all), nor the 3rd parties libraries
> (the code
> that relies on them can be built as an extension by anyone
> who wants),
> but the lack of man power with the knowledge to maintain
> and further
> develop it.
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
Re: Report Builder extension (was Re: [proposal] development for the
first AOO release)
Posted by Ariel Constenla-Haile <ar...@gmail.com>.
Hello Alexander,
On Thu, Nov 10, 2011 at 11:53:12AM +0100, Alexander Thurgood wrote:
> Le 09/11/11 17:19, Pedro Giffuni a écrit :
>
> Hi Pedro,
>
> > My attempt to contact Pentaho concerning this extension
> > produced no result. I consider this extension orphaned
> > and I think it should be moved elsewhere out.
>
>
> This is most unfortunate. Without a report building module of some kind,
> all the database segment of users will change from OOo to something
> else. Of course, there is still the built-in reportdesign module that
> could be enhanced, but it is relatively unloved and I don't think
> anything much has happened to it since the Pentaho integration into the
> OOo source tree.
the reportbuilder won't be built nor released by AOOo, but anyone can
take the sources and build it (for example, it would be useful to take
the sources and make a Netbeans project out of it).
This extension is not really extension in the real sense of the term
(extending OOo without touching any line of source code), it depends on
the core functionality introduced in the reportdesign module.
AOOo is not removing reportdesign nor reportbuilder.
The main issue is not the source code (on the software grant from
Oracle, so no issue at all), nor the 3rd parties libraries (the code
that relies on them can be built as an extension by anyone who wants),
but the lack of man power with the knowledge to maintain and further
develop it.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: Report Builder extension (was Re: [proposal] development for the first AOO release)
Posted by Pedro Giffuni <pf...@apache.org>.
Alexander;
We are not killing it at all: it is just more difficult
to build.
At this time we are focusing on complying with
ASF IP requirements, on a later stage we will
focus on regaining any lost functionality.
I think this would be better as an external
module but no one is planning to remove it
at all.
Pedro.
--- On Thu, 11/10/11, Alexander Thurgood <al...@gmail.com> wrote:
> Le 09/11/11 17:19, Pedro Giffuni a écrit :
>
> Hi Pedro,
>
> > My attempt to contact Pentaho concerning this
> extension
> > produced no result. I consider this extension
> orphaned
> > and I think it should be moved elsewhere out.
>
>
> This is most unfortunate. Without a report building module
> of some kind,
> all the database segment of users will change from OOo to
> something
> else. Of course, there is still the built-in reportdesign
> module that
> could be enhanced, but it is relatively unloved and I don't
> think
> anything much has happened to it since the Pentaho
> integration into the
> OOo source tree.
>
>
> Alex
>
>
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Alexander Thurgood <al...@gmail.com>.
Le 09/11/11 17:19, Pedro Giffuni a écrit :
Hi Pedro,
> My attempt to contact Pentaho concerning this extension
> produced no result. I consider this extension orphaned
> and I think it should be moved elsewhere out.
This is most unfortunate. Without a report building module of some kind,
all the database segment of users will change from OOo to something
else. Of course, there is still the built-in reportdesign module that
could be enhanced, but it is relatively unloved and I don't think
anything much has happened to it since the Pentaho integration into the
OOo source tree.
Alex
Re: Report Builder extension (was Re: [proposal] development for the first AOO release)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Oliver;
It's OK. The priority is clearly to get the IP
clearance done; I was just trying to set out
some plan to preserve the functionality much
easier for end users but this surely can wait.
Thanks for your hard work,
Pedro.
--- On Fri, 11/11/11, Oliver-Rainer Wittmann wrote:
...
> Hi,
>
> sorry for the late response - I was busy with some other
> stuff.
>
> Yes, I agree - the configure options are too much.
> I did not invest the time to clean it up - I was just using
> and adapting what already exists.
>
> The intrinsic output of the build of module reportbuilder
> is an extension for Apache OOo. I kept the build of it with
> the corresponding jars available in the system for everybody
> who wants to bundle it with Apache OOo and/or who wants to
> adjust/enhance/correct it.
> Such an extension is of high value for a certain part of
> our users, but it is an optional functionality. Thus, I think
> it was decided to implement this functionality as an extension.
>
> My main focus here was to make this part of our code IP
> clear.
> If further interest and resources are available in the
> future this
> project will evolve. But currently that was not my focus.
>
> Best regards, Oliver.
>
> On 09.11.2011 17:19, Pedro Giffuni wrote:
> > Hi Oliver;
> >
> > I won't ask you to revert this but I think it's a
> complete
> > waste of time.
> >
> > Those tarballs don't really have a home so it's
> > improbable that someone will get them into their
> > build, plus it's too many flags to get that building.
> >
> > My attempt to contact Pentaho concerning this
> extension
> > produced no result. I consider this extension
> orphaned
> > and I think it should be moved elsewhere out.
> >
> > Pedro.
> >
> > (Yes, I woke up on the left side of the bed
> > today ;-) ).
> >
> > --- On Wed, 11/9/11, Oliver-Rainer Wittmann wrote:
> > ...
> >>
> >> I have finished the improvement - or better the
> >> correction.
> >> Now, it should be possible to build the Report
> Builder
> >> extension with
> >> jars available in the system.
> >> To do so, the following (already existing)
> configure
> >> options have to be
> >> used:
> >> --enable-report-builder
> >> --with-sac-jar=JARFILE
> >> --with-libxml-jar=JARFILE
> >> --with-flute-jar=JARFILE
> >> --with-jfreereport-jar=JARFILE
> >> --with-liblayout-jar=JARFILE
> >> --with-libloader-jar=JARFILE
> >> --with-libloader-jar=JARFILE
> >> --with-libformula-jar=JARFILE
> >> --with-librepository-jar=JARFILE
> >> --with-libfonts-jar=JARFILE
> >> --with-libserializer-jar=JARFILE
> >> --with-libbase-jar=JARFILE
> >>
> >> I have reactivated environment variable
> SYSTEM_JFREEREPORT.
> >> It can not
> >> be used via a configure option, but is by default
> set to
> >> "YES", if
> >> configure option --enable-report-builder is used.
> >>
> >> Thanks again for reporting the defect in my
> contribution.
> >> Again, feedback is welcome.
> >>
> >> Best regards, Oliver.
> >>
>
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
sorry for the late response - I was busy with some other stuff.
Yes, I agree - the configure options are too much.
I did not invest the time to clean it up - I was just using and adapting
what already exists.
The intrinsic output of the build of module reportbuilder is an
extension for Apache OOo. I kept the build of it with the corresponding
jars available in the system for everybody who wants to bundle it with
Apache OOo and/or who wants to adjust/enhance/correct it.
Such an extension is of high value for a certain part of our users, but
it is an optional functionality. Thus, I think it was decided to
implement this functionality as an extension.
My main focus here was to make this part of our code IP clear.
If further interest and resources are available in the future this
project will evolve. But currently that was not my focus.
Best regards, Oliver.
On 09.11.2011 17:19, Pedro Giffuni wrote:
> Hi Oliver;
>
> I won't ask you to revert this but I think it's a complete
> waste of time.
>
> Those tarballs don't really have a home so it's
> improbable that someone will get them into their
> build, plus it's too many flags to get that building.
>
> My attempt to contact Pentaho concerning this extension
> produced no result. I consider this extension orphaned
> and I think it should be moved elsewhere out.
>
> Pedro.
>
> (Yes, I woke up on the left side of the bed
> today ;-) ).
>
> --- On Wed, 11/9/11, Oliver-Rainer Wittmann wrote:
> ...
>>
>> I have finished the improvement - or better the
>> correction.
>> Now, it should be possible to build the Report Builder
>> extension with
>> jars available in the system.
>> To do so, the following (already existing) configure
>> options have to be
>> used:
>> --enable-report-builder
>> --with-sac-jar=JARFILE
>> --with-libxml-jar=JARFILE
>> --with-flute-jar=JARFILE
>> --with-jfreereport-jar=JARFILE
>> --with-liblayout-jar=JARFILE
>> --with-libloader-jar=JARFILE
>> --with-libloader-jar=JARFILE
>> --with-libformula-jar=JARFILE
>> --with-librepository-jar=JARFILE
>> --with-libfonts-jar=JARFILE
>> --with-libserializer-jar=JARFILE
>> --with-libbase-jar=JARFILE
>>
>> I have reactivated environment variable SYSTEM_JFREEREPORT.
>> It can not
>> be used via a configure option, but is by default set to
>> "YES", if
>> configure option --enable-report-builder is used.
>>
>> Thanks again for reporting the defect in my contribution.
>> Again, feedback is welcome.
>>
>> Best regards, Oliver.
>>
Re: Report Builder extension (was Re: [proposal] development for the first AOO release)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Oliver;
I won't ask you to revert this but I think it's a complete
waste of time.
Those tarballs don't really have a home so it's
improbable that someone will get them into their
build, plus it's too many flags to get that building.
My attempt to contact Pentaho concerning this extension
produced no result. I consider this extension orphaned
and I think it should be moved elsewhere out.
Pedro.
(Yes, I woke up on the left side of the bed
today ;-) ).
--- On Wed, 11/9/11, Oliver-Rainer Wittmann wrote:
...
>
> I have finished the improvement - or better the
> correction.
> Now, it should be possible to build the Report Builder
> extension with
> jars available in the system.
> To do so, the following (already existing) configure
> options have to be
> used:
> --enable-report-builder
> --with-sac-jar=JARFILE
> --with-libxml-jar=JARFILE
> --with-flute-jar=JARFILE
> --with-jfreereport-jar=JARFILE
> --with-liblayout-jar=JARFILE
> --with-libloader-jar=JARFILE
> --with-libloader-jar=JARFILE
> --with-libformula-jar=JARFILE
> --with-librepository-jar=JARFILE
> --with-libfonts-jar=JARFILE
> --with-libserializer-jar=JARFILE
> --with-libbase-jar=JARFILE
>
> I have reactivated environment variable SYSTEM_JFREEREPORT.
> It can not
> be used via a configure option, but is by default set to
> "YES", if
> configure option --enable-report-builder is used.
>
> Thanks again for reporting the defect in my contribution.
> Again, feedback is welcome.
>
> Best regards, Oliver.
>
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 07.11.2011 12:42, Oliver-Rainer Wittmann wrote:
>
>
> On 07.11.2011 11:15, Mathias Bauer wrote:
>> On 07.11.2011 09:50, Oliver-Rainer Wittmann wrote:
>>>
>>>
>>> On 03.11.2011 09:16, Mathias Bauer wrote:
>>>> On 02.11.2011 15:52, Oliver-Rainer Wittmann wrote:
>>>>
>>>>> I am not planning to remove the report builder extension.
>>>>> I am planning to remove the 3rd party components which are used by the
>>>>> report builder extension as they are licensed under LGPL.
>>>>> This will have the effect that the report builder will not work
>>>>> anymore.
>>>>> Thus, I have got in mind to disable its building without touching any
>>>>> code of it.
>>>>
>>>> You don't need to do that as by default the report builder isn't
>>>> built. :-)
>>>>
>>>
>>> I know ;-)
>>>
>>> But, I wanted to assure that nobody uses the configure option to enable
>>> the build and then fail.
>>
>> Why prevent others from building Report Builder?
>>
>> We don't build the JFree Report stuff anyway, to build the Report
>> Builder you have to provide the pre-built jars. Currently they are
>> pulled automatically from ext_src, but we could change that to pulling
>> it from "external" like other stuff and throw errors in case the jars
>> aren't there and the switch for building Report Builder is used. So
>> someone who wants to build it just needs to copy the jars to
>> external/jfreereport or so.
>>
>
> I am not simply removing the --enable-report-builder configure option.
>
> The configure script already has a --with-system-jfreereport option
> together with certain --with-...-jar options in order to build the
> report builder extension with system's jars.
>
> Thus, I kept the --enable-report-builder option, but removed the
> --with-system-jfreereport option in order to build _only_ with system's
> jars.
> Unfortunately, my patch was not fully functional - but an improvement is
> in progress. This improvement more or less corrects the existing stuff
> regarding usage of system's jars for jfreereport.
>
I have finished the improvement - or better the correction.
Now, it should be possible to build the Report Builder extension with
jars available in the system.
To do so, the following (already existing) configure options have to be
used:
--enable-report-builder
--with-sac-jar=JARFILE
--with-libxml-jar=JARFILE
--with-flute-jar=JARFILE
--with-jfreereport-jar=JARFILE
--with-liblayout-jar=JARFILE
--with-libloader-jar=JARFILE
--with-libloader-jar=JARFILE
--with-libformula-jar=JARFILE
--with-librepository-jar=JARFILE
--with-libfonts-jar=JARFILE
--with-libserializer-jar=JARFILE
--with-libbase-jar=JARFILE
I have reactivated environment variable SYSTEM_JFREEREPORT. It can not
be used via a configure option, but is by default set to "YES", if
configure option --enable-report-builder is used.
Thanks again for reporting the defect in my contribution.
Again, feedback is welcome.
Best regards, Oliver.
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
On 07.11.2011 11:15, Mathias Bauer wrote:
> On 07.11.2011 09:50, Oliver-Rainer Wittmann wrote:
>>
>>
>> On 03.11.2011 09:16, Mathias Bauer wrote:
>>> On 02.11.2011 15:52, Oliver-Rainer Wittmann wrote:
>>>
>>>> I am not planning to remove the report builder extension.
>>>> I am planning to remove the 3rd party components which are used by the
>>>> report builder extension as they are licensed under LGPL.
>>>> This will have the effect that the report builder will not work
>>>> anymore.
>>>> Thus, I have got in mind to disable its building without touching any
>>>> code of it.
>>>
>>> You don't need to do that as by default the report builder isn't
>>> built. :-)
>>>
>>
>> I know ;-)
>>
>> But, I wanted to assure that nobody uses the configure option to enable
>> the build and then fail.
>
> Why prevent others from building Report Builder?
>
> We don't build the JFree Report stuff anyway, to build the Report
> Builder you have to provide the pre-built jars. Currently they are
> pulled automatically from ext_src, but we could change that to pulling
> it from "external" like other stuff and throw errors in case the jars
> aren't there and the switch for building Report Builder is used. So
> someone who wants to build it just needs to copy the jars to
> external/jfreereport or so.
>
I am not simply removing the --enable-report-builder configure option.
The configure script already has a --with-system-jfreereport option
together with certain --with-...-jar options in order to build the
report builder extension with system's jars.
Thus, I kept the --enable-report-builder option, but removed the
--with-system-jfreereport option in order to build _only_ with system's
jars.
Unfortunately, my patch was not fully functional - but an improvement is
in progress. This improvement more or less corrects the existing stuff
regarding usage of system's jars for jfreereport.
Best regards, Oliver.
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 07.11.2011 09:50, Oliver-Rainer Wittmann wrote:
>
>
> On 03.11.2011 09:16, Mathias Bauer wrote:
>> On 02.11.2011 15:52, Oliver-Rainer Wittmann wrote:
>>
>>> I am not planning to remove the report builder extension.
>>> I am planning to remove the 3rd party components which are used by the
>>> report builder extension as they are licensed under LGPL.
>>> This will have the effect that the report builder will not work anymore.
>>> Thus, I have got in mind to disable its building without touching any
>>> code of it.
>>
>> You don't need to do that as by default the report builder isn't
>> built. :-)
>>
>
> I know ;-)
>
> But, I wanted to assure that nobody uses the configure option to enable
> the build and then fail.
Why prevent others from building Report Builder?
We don't build the JFree Report stuff anyway, to build the Report
Builder you have to provide the pre-built jars. Currently they are
pulled automatically from ext_src, but we could change that to pulling
it from "external" like other stuff and throw errors in case the jars
aren't there and the switch for building Report Builder is used. So
someone who wants to build it just needs to copy the jars to
external/jfreereport or so.
Regards,
Mathias
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
On 03.11.2011 09:16, Mathias Bauer wrote:
> On 02.11.2011 15:52, Oliver-Rainer Wittmann wrote:
>
>> I am not planning to remove the report builder extension.
>> I am planning to remove the 3rd party components which are used by the
>> report builder extension as they are licensed under LGPL.
>> This will have the effect that the report builder will not work anymore.
>> Thus, I have got in mind to disable its building without touching any
>> code of it.
>
> You don't need to do that as by default the report builder isn't built. :-)
>
I know ;-)
But, I wanted to assure that nobody uses the configure option to enable
the build and then fail.
Best regards, Oliver.
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 02.11.2011 15:52, Oliver-Rainer Wittmann wrote:
> I am not planning to remove the report builder extension.
> I am planning to remove the 3rd party components which are used by the
> report builder extension as they are licensed under LGPL.
> This will have the effect that the report builder will not work anymore.
> Thus, I have got in mind to disable its building without touching any
> code of it.
You don't need to do that as by default the report builder isn't built. :-)
Regards,
Mathias
Re: [proposal] development for the first AOO release
Posted by Pedro Giffuni <pf...@apache.org>.
--- On Wed, 11/2/11, Jürgen Schmidt wrote:
>
> >
> > BTW, most of the reportbuilder dependencies come from
> > Pentaho right? We should contact them and let them
> > know the situation.
> >
> probably worth to try it
>
I will contact them.
best regards,
Pedro.
Re: [proposal] development for the first AOO release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 11/2/11 4:50 PM, Pedro Giffuni wrote:
>
> --- On Wed, 11/2/11, Oliver-Rainer Wittmann<or...@googlemail.com> wrote:
> ...
>>
>> I am not sure, if we are on the same page ;-)
>>
>
> I expressed it badly indeed. I meant we are not yet removing
> any code that we have an SGA for. We do have an SGA for the
> reportbuilder but not the dependencies so the dependencies
> can go. We can disable them in configure.in for now but we
> will have to find somewhere to put them later on.
exactly, that is the way i have understand it as well. Our goal should
be to become Apache conform with our code base as soon as possible.
>
> BTW, most of the reportbuilder dependencies come from Pentaho
> right? We should contact them and let them know the situation.
>
probably worth to try it
Juergen
> cheers,
>
> Pedro.
>
>
>>
>> BTW, I do not think that any used 3rd party component on
>> which Oracle has no copyright on will be covered by
>> Oracle's SGA.
>>
>
> I won't say it works out this way every time but I have had
> luck getting some dependencies to relicense :).
>>
Re: [proposal] development for the first AOO release
Posted by Pedro Giffuni <pf...@apache.org>.
--- On Wed, 11/2/11, Oliver-Rainer Wittmann <or...@googlemail.com> wrote:
...
>
> I am not sure, if we are on the same page ;-)
>
I expressed it badly indeed. I meant we are not yet removing
any code that we have an SGA for. We do have an SGA for the
reportbuilder but not the dependencies so the dependencies
can go. We can disable them in configure.in for now but we
will have to find somewhere to put them later on.
BTW, most of the reportbuilder dependencies come from Pentaho
right? We should contact them and let them know the situation.
cheers,
Pedro.
>
> BTW, I do not think that any used 3rd party component on
> which Oracle has no copyright on will be covered by
> Oracle's SGA.
>
I won't say it works out this way every time but I have had
luck getting some dependencies to relicense :).
>
Re: [proposal] development for the first AOO release
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Pedro,
On 02.11.2011 16:03, Pedro Giffuni wrote:
>
>
> --- On Wed, 11/2/11, Oliver-Rainer Wittmann<or...@googlemail.com> wrote:
>
>>
>> BTW, nothing is lost by this removal step - everything is
>> still in the repository. This certain documentation in a
>> Bugzilla issue the stuff can be recovered easily for future
>> usage and adjustment.
>>
> Ahh.. OK. We are on the same page then. No removed functionality
> until we know what will replace it and the SGA is in.
>
I am not sure, if we are on the same page ;-)
As 3rd party compoments which violate Apache's Third-Party Licensing
Policy are not allowed they have to be removed.
Thus one part of the tasks for the proposed "IP cleared" milestone are
to remove these without having deeply thought about a replacement. Thus,
we will lose certain features - like the report builder extension.
It is the subject of the next proposed "features back" milestone to
identify the features which should be brought back and for which
corresponding interest and resources are available.
BTW, I do not think that any used 3rd party component on which Oracle
has no copyright on will be covered by Oracle's SGA.
Best regards, Oliver.
Re: Report Builder extension (was Re: [proposal] development for the first AOO release)
Posted by Pedro Giffuni <pf...@apache.org>.
--- On Wed, 11/2/11, Oliver-Rainer Wittmann <or...@googlemail.com> wrote:
>
> BTW, nothing is lost by this removal step - everything is
> still in the repository. This certain documentation in a
> Bugzilla issue the stuff can be recovered easily for future
> usage and adjustment.
>
Ahh.. OK. We are on the same page then. No removed functionality
until we know what will replace it and the SGA is in.
Cheers,
Pedro.
Re: Report Builder extension (was Re: [proposal] development for
the first AOO release)
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Pedro,
On 02.11.2011 15:18, Pedro Giffuni wrote:
> Hi Oliver;
>
> What do you mean by "removal of the 3rd party components"?
>
- Removing the components and its references out of the repository.
- Adjusting the code which is using these components - e.g. switching
off the corresponding functions.
> I think the report builder should be moved to Apache-extras
> with three suggestions:
>
> - Attempt to contact the authors of the pentaho stuff,
> maybe they would like to have a say in it's future or
> even relicense it.
> -Wait until the headers are changed to AL2, before moving
> it out.
> - Rob has a SVN dump: maybe we can use it to preserve most
> of the early history of the stuff we move to Apache-extras.
>
I am not planning to remove the report builder extension.
I am planning to remove the 3rd party components which are used by the
report builder extension as they are licensed under LGPL.
This will have the effect that the report builder will not work anymore.
Thus, I have got in mind to disable its building without touching any
code of it.
Then our code base regarding the report builder extension will be clean
due to Apache's Third-Party Licensing Policy.
BTW, nothing is lost by this removal step - everything is still in the
repository. This certain documentation in a Bugzilla issue the stuff can
be recovered easily for future usage and adjustment.
Best regards, Oliver.