Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO

[Rony G Flatscher]

Thank you as well, also for the link which I was not aware of! 

—-rony

Rony G. Flatscher (mobil/e)

> Am 10.12.2020 um 12:49 schrieb Matthias Seidel :
> 
> Hi all,
> 
>> Am 10.12.20 um 01:59 schrieb Peter Kovacs:
>> Thank you Rony for the Java deep dive.
> 
> +1
> 
> And BTW:
> 
> https://www.youtube.com/watch?v=p4DeOilMOQA
> 
> Regards,
> 
>Matthias
> 
>> 
>>> On 08.12.20 19:11, Rony G. Flatscher (Apache) wrote:
>>> Hmm, just some thoughts and pointers that may be helpful in the
>>> context of the current Java and
>>> possibly HSQL discussions.
>>> 
>>> Ad Java and OpenOffice
>>> 
>>>  IMHO Java has been fulfilling Sun's original promise "write
>>> once, run everywhere" in a very
>>>  impressive way for decades by  now! When Sun (being the inventor
>>> of Java) bought Star Division
>>>  to acquire StarOffice and making the source also available via
>>> openoffice.org, Sun also had the
>>>  Java interfaces put into the office suite, such that Java
>>> programmers would be able to interface
>>>  with OOo (using "OOo" to also mean AOO and the LO-fork) via UNO
>>> to this very day, and also
>>>  enabling Java to become an additional programming language to
>>> C++ to create OOo packages. This
>>>  has been some achievement and to me has been impressive to this
>>> very day!
>>> 
>>>  Java AOO components and Java applications interacting with AOO
>>> have been working for almost
>>>  decades without a need of change! (Also such applications would
>>> be deployable on different
>>>  operating systems without a need to rewrite and recompile them!)
>>> 
>>>  Discussing removing Java dependencies given this history and
>>> integration makes me a little bit
>>>  nervous if looking at some of the arguments, which may go back
>>> to misconceptions, hear-say and
>>>  possibly wrong information published about Java (like Oracle's
>>> change in its license would make
>>>  it impossible for software XXX to continue to use it ... which
>>> simply is not the case).
>>> 
>>>  The scripting interface to OOo is written in Java. Therefore it
>>> has become possible to use the
>>>  Java implemented scripting languages JavaScript and BeanShell to
>>> create OOo macros, besides OOo
>>>  Basic and Python. In addition - as others have done also - I
>>> authored a little package that uses
>>>  the OOo scripting interface in order to make another scripting
>>> language (ooRexx [1]) available
>>>  as an OOo macro language (one package creates a bidirectional
>>> bridge between ooRexx and Java
>>>  [2], the other package camouflages UNO as ooRexx and exploits
>>> the UNO reflection mechanism to
>>>  make it easy on programmers to interface with OOo [3]), so this
>>> is one reason, why being a
>>>  little bit nervous about a possible wrong assessment of Java...
>>> 
>>> Ad Java Distributions
>>> 
>>>  It seems that many people think that Java is only available in a
>>> proprietary form from Oracle
>>>  [4], which changed its license terms for its Java 1.8/8 and up,
>>> around the time when modular
>>>  Java (Java 9) got released. Oracle is regarded to be the owner
>>> of Java and therefore people tend
>>>  to think that there is no open-source, free alternative
>>> available, which is not correct.
>>> 
>>>  Enter "OpenJDK" [5] the open-source version of Java: this allows
>>> you to use Java for free (it is
>>>  GPL with the CLASSPATH exception license such that your code
>>> using it does not fall under GPL
>>>  automatically). With the modular versions of Java, starting with
>>> Java 9, one is even able to
>>>  create one own's Java (runtime environment, JRE) by combining
>>> the Java modules one wishes to
>>>  deploy[6]. (This would even open up the opportunity for OOo to
>>> create and distribute its own
>>>  tailored JRE, should such a need arise.)
>>> 
>>>  If you do not feel inclined to create your own JRE (Java
>>> runtime-environment) then you can
>>>  download Java=OpenJDK JRE for your particular platform from e.g.
>>> AdoptOpenJDK [7], Liberica [8]
>>>  or Zulu [9] to name a few.
>>> 
>>>  So Java is available in an open-source and free form with the
>>> term OpenJDK (open Java
>>>  development kit) [5].
>>> 
>>>  One tidbit in this "license" context: programmers who wish to
>>> contribute to Java/OpenJDK must
>>>  sign an "OCA" (Oracle contributer agreement [15]) giving more or
>>> less all rights on the
>>>  contributed software to Oracle which then makes the software
>>> available to the OpenJDK with GPL
>>>  and the CLASSPATH exception. Something that Sun had done with
>>> software contributed to OOo. This
>>>  BTW allowed later Oracle (after buying Sun and acquiring all of
>>> Sun's software rights) to
>>>  contribute the OOo source code to the Apache software
>>> foundation, making it in the end possible
>>>  to create and release AOO 

Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO

[Matthias Seidel]

Hi all,

Am 10.12.20 um 01:59 schrieb Peter Kovacs:
> Thank you Rony for the Java deep dive.

+1

And BTW:

https://www.youtube.com/watch?v=p4DeOilMOQA

Regards,

   Matthias

>
> On 08.12.20 19:11, Rony G. Flatscher (Apache) wrote:
>> Hmm, just some thoughts and pointers that may be helpful in the
>> context of the current Java and
>> possibly HSQL discussions.
>>
>> Ad Java and OpenOffice
>>
>>  IMHO Java has been fulfilling Sun's original promise "write
>> once, run everywhere" in a very
>>  impressive way for decades by  now! When Sun (being the inventor
>> of Java) bought Star Division
>>  to acquire StarOffice and making the source also available via
>> openoffice.org, Sun also had the
>>  Java interfaces put into the office suite, such that Java
>> programmers would be able to interface
>>  with OOo (using "OOo" to also mean AOO and the LO-fork) via UNO
>> to this very day, and also
>>  enabling Java to become an additional programming language to
>> C++ to create OOo packages. This
>>  has been some achievement and to me has been impressive to this
>> very day!
>>
>>  Java AOO components and Java applications interacting with AOO
>> have been working for almost
>>  decades without a need of change! (Also such applications would
>> be deployable on different
>>  operating systems without a need to rewrite and recompile them!)
>>
>>  Discussing removing Java dependencies given this history and
>> integration makes me a little bit
>>  nervous if looking at some of the arguments, which may go back
>> to misconceptions, hear-say and
>>  possibly wrong information published about Java (like Oracle's
>> change in its license would make
>>  it impossible for software XXX to continue to use it ... which
>> simply is not the case).
>>
>>  The scripting interface to OOo is written in Java. Therefore it
>> has become possible to use the
>>  Java implemented scripting languages JavaScript and BeanShell to
>> create OOo macros, besides OOo
>>  Basic and Python. In addition - as others have done also - I
>> authored a little package that uses
>>  the OOo scripting interface in order to make another scripting
>> language (ooRexx [1]) available
>>  as an OOo macro language (one package creates a bidirectional
>> bridge between ooRexx and Java
>>  [2], the other package camouflages UNO as ooRexx and exploits
>> the UNO reflection mechanism to
>>  make it easy on programmers to interface with OOo [3]), so this
>> is one reason, why being a
>>  little bit nervous about a possible wrong assessment of Java...
>>
>> Ad Java Distributions
>>
>>  It seems that many people think that Java is only available in a
>> proprietary form from Oracle
>>  [4], which changed its license terms for its Java 1.8/8 and up,
>> around the time when modular
>>  Java (Java 9) got released. Oracle is regarded to be the owner
>> of Java and therefore people tend
>>  to think that there is no open-source, free alternative
>> available, which is not correct.
>>
>>  Enter "OpenJDK" [5] the open-source version of Java: this allows
>> you to use Java for free (it is
>>  GPL with the CLASSPATH exception license such that your code
>> using it does not fall under GPL
>>  automatically). With the modular versions of Java, starting with
>> Java 9, one is even able to
>>  create one own's Java (runtime environment, JRE) by combining
>> the Java modules one wishes to
>>  deploy[6]. (This would even open up the opportunity for OOo to
>> create and distribute its own
>>  tailored JRE, should such a need arise.)
>>
>>  If you do not feel inclined to create your own JRE (Java
>> runtime-environment) then you can
>>  download Java=OpenJDK JRE for your particular platform from e.g.
>> AdoptOpenJDK [7], Liberica [8]
>>  or Zulu [9] to name a few.
>>
>>  So Java is available in an open-source and free form with the
>> term OpenJDK (open Java
>>  development kit) [5].
>>
>>  One tidbit in this "license" context: programmers who wish to
>> contribute to Java/OpenJDK must
>>  sign an "OCA" (Oracle contributer agreement [15]) giving more or
>> less all rights on the
>>  contributed software to Oracle which then makes the software
>> available to the OpenJDK with GPL
>>  and the CLASSPATH exception. Something that Sun had done with
>> software contributed to OOo. This
>>  BTW allowed later Oracle (after buying Sun and acquiring all of
>> Sun's software rights) to
>>  contribute the OOo source code to the Apache software
>> foundation, making it in the end possible
>>  to create and release AOO under the Apache license! (BTW, one
>> would be able to release one
>>  own's, contributed code with additional, different licenses.
>> Something that would also be
>>  possible for e.g. LO-contributors, but many are not aware of
>> this it seems.)
>>
>> Ad Java 1.8/8 Versus Java 9 and Later ...

Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO

[Peter Kovacs]

Thank you Rony for the Java deep dive.

On 08.12.20 19:11, Rony G. Flatscher (Apache) wrote:

Hmm, just some thoughts and pointers that may be helpful in the context of the 
current Java and
possibly HSQL discussions.

Ad Java and OpenOffice

 IMHO Java has been fulfilling Sun's original promise "write once, run 
everywhere" in a very
 impressive way for decades by  now! When Sun (being the inventor of Java) 
bought Star Division
 to acquire StarOffice and making the source also available via 
openoffice.org, Sun also had the
 Java interfaces put into the office suite, such that Java programmers 
would be able to interface
 with OOo (using "OOo" to also mean AOO and the LO-fork) via UNO to this 
very day, and also
 enabling Java to become an additional programming language to C++ to 
create OOo packages. This
 has been some achievement and to me has been impressive to this very day!

 Java AOO components and Java applications interacting with AOO have been 
working for almost
 decades without a need of change! (Also such applications would be 
deployable on different
 operating systems without a need to rewrite and recompile them!)

 Discussing removing Java dependencies given this history and integration 
makes me a little bit
 nervous if looking at some of the arguments, which may go back to 
misconceptions, hear-say and
 possibly wrong information published about Java (like Oracle's change in 
its license would make
 it impossible for software XXX to continue to use it ... which simply is 
not the case).

 The scripting interface to OOo is written in Java. Therefore it has become 
possible to use the
 Java implemented scripting languages JavaScript and BeanShell to create 
OOo macros, besides OOo
 Basic and Python. In addition - as others have done also - I authored a 
little package that uses
 the OOo scripting interface in order to make another scripting language 
(ooRexx [1]) available
 as an OOo macro language (one package creates a bidirectional bridge 
between ooRexx and Java
 [2], the other package camouflages UNO as ooRexx and exploits the UNO 
reflection mechanism to
 make it easy on programmers to interface with OOo [3]), so this is one 
reason, why being a
 little bit nervous about a possible wrong assessment of Java...

Ad Java Distributions

 It seems that many people think that Java is only available in a 
proprietary form from Oracle
 [4], which changed its license terms for its Java 1.8/8 and up, around the 
time when modular
 Java (Java 9) got released. Oracle is regarded to be the owner of Java and 
therefore people tend
 to think that there is no open-source, free alternative available, which 
is not correct.

 Enter "OpenJDK" [5] the open-source version of Java: this allows you to 
use Java for free (it is
 GPL with the CLASSPATH exception license such that your code using it does 
not fall under GPL
 automatically). With the modular versions of Java, starting with Java 9, 
one is even able to
 create one own's Java (runtime environment, JRE) by combining the Java 
modules one wishes to
 deploy[6]. (This would even open up the opportunity for OOo to create and 
distribute its own
 tailored JRE, should such a need arise.)

 If you do not feel inclined to create your own JRE (Java 
runtime-environment) then you can
 download Java=OpenJDK JRE for your particular platform from e.g. 
AdoptOpenJDK [7], Liberica [8]
 or Zulu [9] to name a few.

 So Java is available in an open-source and free form with the term OpenJDK 
(open Java
 development kit) [5].

 One tidbit in this "license" context: programmers who wish to contribute 
to Java/OpenJDK must
 sign an "OCA" (Oracle contributer agreement [15]) giving more or less all 
rights on the
 contributed software to Oracle which then makes the software available to 
the OpenJDK with GPL
 and the CLASSPATH exception. Something that Sun had done with software 
contributed to OOo. This
 BTW allowed later Oracle (after buying Sun and acquiring all of Sun's 
software rights) to
 contribute the OOo source code to the Apache software foundation, making 
it in the end possible
 to create and release AOO under the Apache license! (BTW, one would be 
able to release one
 own's, contributed code with additional, different licenses. Something 
that would also be
 possible for e.g. LO-contributors, but many are not aware of this it 
seems.)

Ad Java 1.8/8 Versus Java 9 and Later ...

 Java 9 got introduced in the fall of 2017 [10]. There are a few notable 
changes:

   * one being that Java has been finally modularized: internal and 
reflective code now is
 access-based (using the package java.lang.invoke), such that 
setAccessible as used in the
 prior versions via the java.lang.reflect package in order to invoke 
reflectively will not be
 

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

Hello Mechtilde, 

> -Original Message-
> From: Mechtilde [mailto:o...@mechtilde.de] 
> Sent: Tuesday, December 08, 2020 2:08 PM
> To: dev@openoffice.apache.org
> Subject: Re: [discussion] future embedded DB in AOO
> 
> Hello Jörg,
> 
> Am 08.12.20 um 11:29 schrieb Jörg Schmidt:
> >  
> > 
> >> -Original Message-
> >> From: Mechtilde [mailto:o...@mechtilde.de] 
> >> Sent: Tuesday, December 08, 2020 10:34 AM
> >> To: dev@openoffice.apache.org
> >> Subject: Re: [discussion] future embedded DB in AOO
> > 
> >>> As far as I know from Mathias Java is, in the long run, a 
> >> problem because of the licensing policy of Oracle(*) and we 
> >> have to find ways to free ourselves from this dependency.
> >>
> >> This isn't a problem anymore, because we can use Adopt 
> >> OpenJDK, which is
> >> used in the linux distributions since long time.
> > 
> > I know that OpenJDK can be used as an alternative in Linux, 
> but what is the situation in Windows? I have no experience 
> with OpenJDK in Windows. 
> > 
> 
> this is also available for Windows

That is clear, but what are the practical experiences?

Excuse me, I was the only one who was made aware of the Java problem by Mathias 
(about 1.5 years ago?) and at that time the OpenJDK seemed to me to be a little 
bit critical (in Mathias' evaluation but also in third parties' evaluation).

It would be/is of course great if there were no more considerations, just in a 
discussion that Peter also considers strategic, one should question such things 
as a precaution.
That is all I am interested in.


greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Java, OOo, ... (Re: [discussion] future embedded DB in AOO

[Rony G. Flatscher (Apache)]

Hmm, just some thoughts and pointers that may be helpful in the context of the 
current Java and
possibly HSQL discussions.

Ad Java and OpenOffice

IMHO Java has been fulfilling Sun's original promise "write once, run 
everywhere" in a very
impressive way for decades by  now! When Sun (being the inventor of Java) 
bought Star Division
to acquire StarOffice and making the source also available via 
openoffice.org, Sun also had the
Java interfaces put into the office suite, such that Java programmers would 
be able to interface
with OOo (using "OOo" to also mean AOO and the LO-fork) via UNO to this 
very day, and also
enabling Java to become an additional programming language to C++ to create 
OOo packages. This
has been some achievement and to me has been impressive to this very day!

Java AOO components and Java applications interacting with AOO have been 
working for almost
decades without a need of change! (Also such applications would be 
deployable on different
operating systems without a need to rewrite and recompile them!)

Discussing removing Java dependencies given this history and integration 
makes me a little bit
nervous if looking at some of the arguments, which may go back to 
misconceptions, hear-say and
possibly wrong information published about Java (like Oracle's change in 
its license would make
it impossible for software XXX to continue to use it ... which simply is 
not the case).

The scripting interface to OOo is written in Java. Therefore it has become 
possible to use the
Java implemented scripting languages JavaScript and BeanShell to create OOo 
macros, besides OOo
Basic and Python. In addition - as others have done also - I authored a 
little package that uses
the OOo scripting interface in order to make another scripting language 
(ooRexx [1]) available
as an OOo macro language (one package creates a bidirectional bridge 
between ooRexx and Java
[2], the other package camouflages UNO as ooRexx and exploits the UNO 
reflection mechanism to
make it easy on programmers to interface with OOo [3]), so this is one 
reason, why being a
little bit nervous about a possible wrong assessment of Java...

Ad Java Distributions

It seems that many people think that Java is only available in a 
proprietary form from Oracle
[4], which changed its license terms for its Java 1.8/8 and up, around the 
time when modular
Java (Java 9) got released. Oracle is regarded to be the owner of Java and 
therefore people tend
to think that there is no open-source, free alternative available, which is 
not correct.

Enter "OpenJDK" [5] the open-source version of Java: this allows you to use 
Java for free (it is
GPL with the CLASSPATH exception license such that your code using it does 
not fall under GPL
automatically). With the modular versions of Java, starting with Java 9, 
one is even able to
create one own's Java (runtime environment, JRE) by combining the Java 
modules one wishes to
deploy[6]. (This would even open up the opportunity for OOo to create and 
distribute its own
tailored JRE, should such a need arise.)

If you do not feel inclined to create your own JRE (Java 
runtime-environment) then you can
download Java=OpenJDK JRE for your particular platform from e.g. 
AdoptOpenJDK [7], Liberica [8]
or Zulu [9] to name a few.

So Java is available in an open-source and free form with the term OpenJDK 
(open Java
development kit) [5].

One tidbit in this "license" context: programmers who wish to contribute to 
Java/OpenJDK must
sign an "OCA" (Oracle contributer agreement [15]) giving more or less all 
rights on the
contributed software to Oracle which then makes the software available to 
the OpenJDK with GPL
and the CLASSPATH exception. Something that Sun had done with software 
contributed to OOo. This
BTW allowed later Oracle (after buying Sun and acquiring all of Sun's 
software rights) to
contribute the OOo source code to the Apache software foundation, making it 
in the end possible
to create and release AOO under the Apache license! (BTW, one would be able 
to release one
own's, contributed code with additional, different licenses. Something that 
would also be
possible for e.g. LO-contributors, but many are not aware of this it seems.)

Ad Java 1.8/8 Versus Java 9 and Later ...

Java 9 got introduced in the fall of 2017 [10]. There are a few notable 
changes:

  * one being that Java has been finally modularized: internal and 
reflective code now is
access-based (using the package java.lang.invoke), such that 
setAccessible as used in the
prior versions via the java.lang.reflect package in order to invoke 
reflectively will not be
allowed anymore. In the transition phase this may cause many, many 
problems with code that
was created prior to Java 9, such that for some 

Re: [discussion] future embedded DB in AOO

[Matthias Seidel]

Hi Damjan,

Am 08.12.20 um 03:06 schrieb Damjan Jovanovic:
> On Mon, Dec 7, 2020 at 8:38 PM Peter Kovacs  wrote:
>
>> Hi all,
>>
>> I would like to know how you guys feel we should move on with our base
>> Database. Our current strategy is a small sized embedded DB using HSQLDB
>> (BSD). There are 2 other options in the same weight class, that is H2
>> (EPL1 or MPL2) and Apache Derby (AL2).
>>
>> Something like SQLLite (PublicDomain) could be technical interesting,
>> but I think their licensing is not so appealing.
>>
>> We could also consider firebird (MPL) like LO, but I have the impression
>> that this is not a lightweight DB, but featurerich. And I wonder if this
>> is really something we should provide. I would rather develop a way to
>> make it easy to switch the DB when a Project grows.
>>
>> What are your thoughts?
>>
>>
> Whatever we do, we have to provide backward compatibility for HSQLDB.

H2 has several compatibility modes icl. HSQLDB:

https://www.h2database.com/html/features.html#feature_list

Regards,

   Matthias

>
> I am more interested in something like Apache Calcite, which would let us
> do SQL queries spanning multiple database backends, than in yet another
> database backend.
>
> SQLite is interesting because it's very widely used, runs on iPhone and
> Android, is a single file, performs well, and is lightweight.
>
> The hard part is getting the database to write into .ODB files instead of
> what it natively uses?
>
> Damjan
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [discussion] future embedded DB in AOO

[Dave Fisher]

> On Dec 8, 2020, at 2:47 AM, Peter Kovacs  wrote:
> 
> 
> On 08.12.20 03:06, Damjan Jovanovic wrote:
>> On Mon, Dec 7, 2020 at 8:38 PM Peter Kovacs  wrote:
>> 
>>> Hi all,
>>> 
>>> I would like to know how you guys feel we should move on with our base
>>> Database. Our current strategy is a small sized embedded DB using HSQLDB
>>> (BSD). There are 2 other options in the same weight class, that is H2
>>> (EPL1 or MPL2) and Apache Derby (AL2).
>>> 
>>> Something like SQLLite (PublicDomain) could be technical interesting,
>>> but I think their licensing is not so appealing.
>>> 
>>> We could also consider firebird (MPL) like LO, but I have the impression
>>> that this is not a lightweight DB, but featurerich. And I wonder if this
>>> is really something we should provide. I would rather develop a way to
>>> make it easy to switch the DB when a Project grows.
>>> 
>>> What are your thoughts?
>>> 
>>> 
>> Whatever we do, we have to provide backward compatibility for HSQLDB.
>> 
>> I am more interested in something like Apache Calcite, which would let us
>> do SQL queries spanning multiple database backends, than in yet another
>> database backend.
> 
> This is an interesting approach. However it is not clear to me on the use.

Base can then sit on top of Big Data / NoSQL as an Analytics engine for the 
rest of us.

> 
> We get a half baked DB System and need to add stuff like Data Handling right?
> 
> And here we need also to write a loader for ODB files. Would we need an In 
> memory Data representation model, too?
> 
> It maybe that we have the basics from Calc, but we still need some work, I 
> think.
> 
>> 
>> SQLite is interesting because it's very widely used, runs on iPhone and
>> Android, is a single file, performs well, and is lightweight.
>> 
>> The hard part is getting the database to write into .ODB files instead of
>> what it natively uses?
> Indeed a topic I did not look into. Actually how is it done today? I do not 
> believe HSSQLDB has a capability for that, right?
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Rory O'Farrell]

On Tue, 8 Dec 2020 14:26:45 +0100
Matthias Seidel  wrote:

> Hi Mechtilde,
> 
> Am 08.12.20 um 14:07 schrieb Mechtilde:
> > Hello Jörg,
> >
> > Am 08.12.20 um 11:29 schrieb Jörg Schmidt:
> >>  
> >>
> >>> -Original Message-
> >>> From: Mechtilde [mailto:o...@mechtilde.de] 
> >>> Sent: Tuesday, December 08, 2020 10:34 AM
> >>> To: dev@openoffice.apache.org
> >>> Subject: Re: [discussion] future embedded DB in AOO
> >>>> As far as I know from Mathias Java is, in the long run, a 
> >>> problem because of the licensing policy of Oracle(*) and we 
> >>> have to find ways to free ourselves from this dependency.
> >>>
> >>> This isn't a problem anymore, because we can use Adopt 
> >>> OpenJDK, which is
> >>> used in the linux distributions since long time.
> >> I know that OpenJDK can be used as an alternative in Linux, but what is 
> >> the situation in Windows? I have no experience with OpenJDK in Windows. 
> >>
> > this is also available for Windows
> 
> Indeed, all my Windows test build are done with AdoptOpenJDK for quite
> some time now and we officially support AdoptOpenJDK (on every platform)
> since AOO 4.1.7 [1]
> 
> Regards,
> 
>    Matthias
> 
> [1]
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.7+Release+Notes#AOO4.1.7ReleaseNotes-Improvements/Enhancements
> 
> >
> >> Jörg
> >
> 

Have used AdoptOpenJDK on Xubuntu towards end of 18:04 and since launch of 
20:04 on several computers with no problem.

-- 
Rory O'Farrell 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Matthias Seidel]

Hi Mechtilde,

Am 08.12.20 um 14:07 schrieb Mechtilde:
> Hello Jörg,
>
> Am 08.12.20 um 11:29 schrieb Jörg Schmidt:
>>  
>>
>>> -Original Message-
>>> From: Mechtilde [mailto:o...@mechtilde.de] 
>>> Sent: Tuesday, December 08, 2020 10:34 AM
>>> To: dev@openoffice.apache.org
>>> Subject: Re: [discussion] future embedded DB in AOO
>>>> As far as I know from Mathias Java is, in the long run, a 
>>> problem because of the licensing policy of Oracle(*) and we 
>>> have to find ways to free ourselves from this dependency.
>>>
>>> This isn't a problem anymore, because we can use Adopt 
>>> OpenJDK, which is
>>> used in the linux distributions since long time.
>> I know that OpenJDK can be used as an alternative in Linux, but what is the 
>> situation in Windows? I have no experience with OpenJDK in Windows. 
>>
> this is also available for Windows

Indeed, all my Windows test build are done with AdoptOpenJDK for quite
some time now and we officially support AdoptOpenJDK (on every platform)
since AOO 4.1.7 [1]

Regards,

   Matthias

[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.7+Release+Notes#AOO4.1.7ReleaseNotes-Improvements/Enhancements

>
>> Jörg
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [discussion] future embedded DB in AOO

[Carl Marcum]

On 12/7/20 4:11 PM, Jim Jagielski wrote:

I agree that eating our own dogfood and using Derby would be the "better" path 
to take; plus it is relatively small while at the same time being quite powerful and 
compliant.
I think that is a good case for Derby over the others unless one has 
compelling features not offered.





On Dec 7, 2020, at 2:46 PM, Jörg Schmidt  wrote:

Hello,


-Original Message-
From: Peter Kovacs [mailto:pe...@apache.org]
Sent: Monday, December 07, 2020 7:38 PM
To: dev@openoffice.apache.org
Subject: [discussion] future embedded DB in AOO

Hi all,

I would like to know how you guys feel we should move on with
our base
Database. ...

There is no compelling reason for us to join LO on the database issue, it may 
even be strategically smart not to.

I know neither H2 nor Apache Derby and have only briefly checked Wikipedia and 
if these two were available I would be in favour of Derby, because:
-obviously better support for SQL
-maybe, due to the longer history, the more mature system
-apparently better encryption features
-Apache Project

But maybe there is an argument for H2:
this project seems to be, in essence, driven by a single developer, most likely 
the one who would welcome H2 to become more known when we use it in AOO and 
would be willing to coordinate the development of H2 with us, so that H2 adapts 
to the requirements of AOO in the best possible way.


With both databases, however, Java bothers me - or have we given up the 
intention of making AOO less dependent on Java?
(yes, of course this is a very long-term question)




greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
<mailto:dev-unsubscr...@openoffice.apache.org>
For additional commands, e-mail: dev-h...@openoffice.apache.org 
<mailto:dev-h...@openoffice.apache.org>



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Mechtilde]

Hello Carl

Am 08.12.20 um 13:56 schrieb Carl Marcum:
> Hi All,
> 
> On 12/7/20 4:11 PM, Jim Jagielski wrote:
>> I agree that eating our own dogfood and using Derby would be the
>> "better" path to take; plus it is relatively small while at the same
>> time being quite powerful and compliant.
> 
> It's not well known but Derby is also rebranded and included in the JDK
> as JavaDB.
> 
> I have used Derby in Embedded and also Client/Server modes and found it
> to be a good solution.
> 
> I do a lot of Grails development and Grails uses H2 in development mode
> and it has a nice web console available.
> I have H2 running as an embedded database for smaller e-commerce clients
> in production without issues.
> 

the main point for me is, for which solution we have the most experience
(wo)man power to implement it.

Kind regards

> Best regards,
> Carl
> 
>>
>>> On Dec 7, 2020, at 2:46 PM, Jörg Schmidt  wrote:
>>>
>>> Hello,
>>>
>>>> -Original Message-
>>>> From: Peter Kovacs [mailto:pe...@apache.org]
>>>> Sent: Monday, December 07, 2020 7:38 PM
>>>> To: dev@openoffice.apache.org
>>>> Subject: [discussion] future embedded DB in AOO
>>>>
>>>> Hi all,
>>>>
>>>> I would like to know how you guys feel we should move on with
>>>> our base
>>>> Database. ...
>>> There is no compelling reason for us to join LO on the database
>>> issue, it may even be strategically smart not to.
>>>
>>> I know neither H2 nor Apache Derby and have only briefly checked
>>> Wikipedia and if these two were available I would be in favour of
>>> Derby, because:
>>> -obviously better support for SQL
>>> -maybe, due to the longer history, the more mature system
>>> -apparently better encryption features
>>> -Apache Project
>>>
>>> But maybe there is an argument for H2:
>>> this project seems to be, in essence, driven by a single developer,
>>> most likely the one who would welcome H2 to become more known when we
>>> use it in AOO and would be willing to coordinate the development of
>>> H2 with us, so that H2 adapts to the requirements of AOO in the best
>>> possible way.
>>>
>>>
>>> With both databases, however, Java bothers me - or have we given up
>>> the intention of making AOO less dependent on Java?
>>> (yes, of course this is a very long-term question)
>>>
>>>
>>>
>>>
>>> greetings,
>>> Jörg
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> <mailto:dev-unsubscr...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>> <mailto:dev-h...@openoffice.apache.org>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

Re: [discussion] future embedded DB in AOO

[Mechtilde]

Hello Jörg,

Am 08.12.20 um 11:29 schrieb Jörg Schmidt:
>  
> 
>> -Original Message-
>> From: Mechtilde [mailto:o...@mechtilde.de] 
>> Sent: Tuesday, December 08, 2020 10:34 AM
>> To: dev@openoffice.apache.org
>> Subject: Re: [discussion] future embedded DB in AOO
> 
>>> As far as I know from Mathias Java is, in the long run, a 
>> problem because of the licensing policy of Oracle(*) and we 
>> have to find ways to free ourselves from this dependency.
>>
>> This isn't a problem anymore, because we can use Adopt 
>> OpenJDK, which is
>> used in the linux distributions since long time.
> 
> I know that OpenJDK can be used as an alternative in Linux, but what is the 
> situation in Windows? I have no experience with OpenJDK in Windows. 
> 

this is also available for Windows

> 
> Jörg


-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

Re: [discussion] future embedded DB in AOO

[Carl Marcum]

Hi All,

On 12/7/20 4:11 PM, Jim Jagielski wrote:

I agree that eating our own dogfood and using Derby would be the "better" path 
to take; plus it is relatively small while at the same time being quite powerful and 
compliant.


It's not well known but Derby is also rebranded and included in the JDK 
as JavaDB.


I have used Derby in Embedded and also Client/Server modes and found it 
to be a good solution.


I do a lot of Grails development and Grails uses H2 in development mode 
and it has a nice web console available.
I have H2 running as an embedded database for smaller e-commerce clients 
in production without issues.


Best regards,
Carl




On Dec 7, 2020, at 2:46 PM, Jörg Schmidt  wrote:

Hello,


-Original Message-
From: Peter Kovacs [mailto:pe...@apache.org]
Sent: Monday, December 07, 2020 7:38 PM
To: dev@openoffice.apache.org
Subject: [discussion] future embedded DB in AOO

Hi all,

I would like to know how you guys feel we should move on with
our base
Database. ...

There is no compelling reason for us to join LO on the database issue, it may 
even be strategically smart not to.

I know neither H2 nor Apache Derby and have only briefly checked Wikipedia and 
if these two were available I would be in favour of Derby, because:
-obviously better support for SQL
-maybe, due to the longer history, the more mature system
-apparently better encryption features
-Apache Project

But maybe there is an argument for H2:
this project seems to be, in essence, driven by a single developer, most likely 
the one who would welcome H2 to become more known when we use it in AOO and 
would be willing to coordinate the development of H2 with us, so that H2 adapts 
to the requirements of AOO in the best possible way.


With both databases, however, Java bothers me - or have we given up the 
intention of making AOO less dependent on Java?
(yes, of course this is a very long-term question)




greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
<mailto:dev-unsubscr...@openoffice.apache.org>
For additional commands, e-mail: dev-h...@openoffice.apache.org 
<mailto:dev-h...@openoffice.apache.org>



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Mechtilde]

Hello Keith,

as i know from former time (before comming to apache)
we evaluate that we can't update HSQL Db to version 2.x. that is the
reason, why also Debian shipped both version of HSQLDB.

Kind regards

Mechtilde

Am 08.12.20 um 03:48 schrieb Keith N. McKenna:
> On 12/7/2020 1:38 PM, Peter Kovacs wrote:
>> Hi all,
>>
>> I would like to know how you guys feel we should move on with our base
>> Database. Our current strategy is a small sized embedded DB using HSQLDB
>> (BSD). There are 2 other options in the same weight class, that is H2
>> (EPL1 or MPL2) and Apache Derby (AL2).
>>
>> Something like SQLLite (PublicDomain) could be technical interesting,
>> but I think their licensing is not so appealing.
>>
>> We could also consider firebird (MPL) like LO, but I have the impression
>> that this is not a lightweight DB, but featurerich. And I wonder if this
>> is really something we should provide. I would rather develop a way to
>> make it easy to switch the DB when a Project grows.
>>
>> What are your thoughts?
>>
>>
>> All the Best
>>
>> Peter
> 
> My first question has to be : Why are we still using such an old version
> of HSQLDB? As memory serves it is `1.8.0 and the latest release of
> HSQLDB is 2.5.1.
> 
> Second is why cannot we upgrade to HSQLDB 2.X.
> 
> As a process engineer and not a programmer these are simple questions I
> need answers for to intelligently contribute to this discussion. Thanks
> all for your understanding.
> 
> Regards
> Keith.
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

> -Original Message-
> From: Matthias Seidel [mailto:matthias.sei...@hamburg.de] 
> Sent: Tuesday, December 08, 2020 11:15 AM
> To: dev@openoffice.apache.org
> Subject: Re: [discussion] future embedded DB in AOO
> 
> Hi Peter,
> 
> If we switch to some other embedded database engine we need 
> to provide a
> way to let users open their existing databases.
> 
> According to the German Wikipedia article [1] H2 provides a
> "compatibility mode" for that purpose.
> 
> Personally I don't see any reason to move away from Java.

If that is so, that is so. But what changed your mind _or did I misrepresent 
your earlier statements about licensing problems_?

(OpenJDK was already a topic back then, but if I remember correctly your 
opinion was rather reserved.)


Jörg






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Peter Kovacs]

On 08.12.20 03:06, Damjan Jovanovic wrote:

On Mon, Dec 7, 2020 at 8:38 PM Peter Kovacs  wrote:


Hi all,

I would like to know how you guys feel we should move on with our base
Database. Our current strategy is a small sized embedded DB using HSQLDB
(BSD). There are 2 other options in the same weight class, that is H2
(EPL1 or MPL2) and Apache Derby (AL2).

Something like SQLLite (PublicDomain) could be technical interesting,
but I think their licensing is not so appealing.

We could also consider firebird (MPL) like LO, but I have the impression
that this is not a lightweight DB, but featurerich. And I wonder if this
is really something we should provide. I would rather develop a way to
make it easy to switch the DB when a Project grows.

What are your thoughts?



Whatever we do, we have to provide backward compatibility for HSQLDB.

I am more interested in something like Apache Calcite, which would let us
do SQL queries spanning multiple database backends, than in yet another
database backend.


This is an interesting approach. However it is not clear to me on the use.

We get a half baked DB System and need to add stuff like Data Handling 
right?


And here we need also to write a loader for ODB files. Would we need an 
In memory Data representation model, too?


It maybe that we have the basics from Calc, but we still need some work, 
I think.




SQLite is interesting because it's very widely used, runs on iPhone and
Android, is a single file, performs well, and is lightweight.

The hard part is getting the database to write into .ODB files instead of
what it natively uses?
Indeed a topic I did not look into. Actually how is it done today? I do 
not believe HSSQLDB has a capability for that, right?



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

 

> -Original Message-
> From: Mechtilde [mailto:o...@mechtilde.de] 
> Sent: Tuesday, December 08, 2020 10:34 AM
> To: dev@openoffice.apache.org
> Subject: Re: [discussion] future embedded DB in AOO

> > As far as I know from Mathias Java is, in the long run, a 
> problem because of the licensing policy of Oracle(*) and we 
> have to find ways to free ourselves from this dependency.
> 
> This isn't a problem anymore, because we can use Adopt 
> OpenJDK, which is
> used in the linux distributions since long time.

I know that OpenJDK can be used as an alternative in Linux, but what is the 
situation in Windows? I have no experience with OpenJDK in Windows. 


Jörg




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Matthias Seidel]

Hi Peter,

If we switch to some other embedded database engine we need to provide a
way to let users open their existing databases.

According to the German Wikipedia article [1] H2 provides a
"compatibility mode" for that purpose.

Personally I don't see any reason to move away from Java.

Regards,

   Matthias

[1] https://de.wikipedia.org/wiki/H2_Database#Funktionen


Am 08.12.20 um 10:14 schrieb Peter Kovacs:
>
> On 08.12.20 09:27, Jörg Schmidt wrote:
>>> -Original Message-
>>> From: Keith N. McKenna [mailto:keith.mcke...@comcast.net]
>>> Sent: Tuesday, December 08, 2020 3:49 AM
>>> To: dev@openoffice.apache.org
>>> Subject: Re: [discussion] future embedded DB in AOO
>>> My first question has to be : Why are we still using such an
>>> old version
>>> of HSQLDB? As memory serves it is `1.8.0 and the latest release of
>>> HSQLDB is 2.5.1.
>
> I thought we had discussion on this, but I could not find them.
>
> I will have later a second look. But this is a good thought. How much
> time will an upgrade bring us?
>
> It will influence the roadmap for sure.
>
>>>
>>> Second is why cannot we upgrade to HSQLDB 2.X.
>
> The question is not if we can, the question is if it is worth it.
>
> I would like to take an early opportunity to look beyond the immediate
> need of  keep things working.
>
> I put on the question what alternative exists. Jörg brought up the
> Question how much Java do we want in future?
>
>>> As a process engineer and not a programmer these are simple
>>> questions I
>>> need answers for to intelligently contribute to this
>>> discussion. Thanks
>>> all for your understanding.
>
> All opinion and thoughts are welcome. I want to find out where we want
> to head with the embedded DB. All Ideas and reasoning can bring up
> good Views.
>
> We can also discuss where we want to go with Base. The question is
> Connected. And Base needs some love, don't you think?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [discussion] future embedded DB in AOO

[Mechtilde]

Hello

onle one statement inside

Am 08.12.20 um 10:23 schrieb Jörg Schmidt:
>  
> 
>> -Original Message-
>> From: Peter Kovacs [mailto:pe...@apache.org] 
>> Sent: Tuesday, December 08, 2020 9:46 AM
>> To: dev@openoffice.apache.org
>> Subject: Re: [discussion] future embedded DB in AOO
>>
>>
>> On 08.12.20 09:14, Jörg Schmidt wrote:
>>>   
>>>
>>>> -Original Message-
>>>> From: Peter Kovacs [mailto:pe...@apache.org]
>>>> Sent: Monday, December 07, 2020 11:03 PM
>>>> To: dev@openoffice.apache.org
>>>> Subject: Re: [discussion] future embedded DB in AOO
>>>>> Maybe one more thing: Is the problem database even important?
>>>> We cannot build with Java 11 and up. Decisions have to be 
>> made soon.
>>>> Strategy has to be setup. A Roadmap would be great
>>> Peter, I do not understand what that means in concrete terms.
>>>
>>> IF Java is a critical factor (I guess because of Oracle's 
>> licensing policy) why is it less so for H2 or Derby than for HSQLDB?
>>
>> No, I meant that building OpenOffice with Java 11 and later 
>> causes the 
>> build to break on hsqldb. So we need to talk
>>
>> what we do. Current state is that we need to change the code 
>> in order to 
>> build on a later Java Version. That is what brought this 
>> topic up. And 
>> again I want to have a discussion on what we head out for. What is 
>> needed. And I think this makes it a good time to collect all 
>> opinions, 
>> arguments and requirements.
> 
> Thank you for this declaration. The situation is therefore understandable to 
> me.
>  
>>> Actually we should rather choose a database that works 
>> without Java(?)
>>>
>>> Also: IF the Java question is urgent, why is it only for 
>> Base? Doesn't belong then on the agenda anymore?
>>
>> Where do I say it is urgent? 
> 
> I had understood "We cannot build with Java 11 and up." that way.
> 
>> This takes time. It is a good time to start this now.
> 
> yes, this is true
> 
> 
>> What is your opinion on Java? Not that I want to start a general Java 
>> discussion, but you are right they are connected.
> 
> As far as I know from Mathias Java is, in the long run, a problem because of 
> the licensing policy of Oracle(*) and we have to find ways to free ourselves 
> from this dependency.

This isn't a problem anymore, because we can use Adopt OpenJDK, which is
used in the linux distributions since long time.
> 
> Since these are rather long-term considerations, I can't say if we have to 
> consider this already now for a decision regarding Base. 
> It would tend to make sense, but searching for a database without Java 
> dependency might collide somewhat with the question of multiplatform 
> capability.
> 
> But please ... I am only answering your question here, I do not want to 
> encourage you to expand the discussion.
> 
> 
> (*)
> if I understood it correctly, the problem is not technical in essence, but 
> future Java versions should be subject to license fees, at least for business 
> use (?)
> 
> Jörg
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

 

> -Original Message-
> From: Peter Kovacs [mailto:pe...@apache.org] 
> Sent: Tuesday, December 08, 2020 9:46 AM
> To: dev@openoffice.apache.org
> Subject: Re: [discussion] future embedded DB in AOO
> 
> 
> On 08.12.20 09:14, Jörg Schmidt wrote:
> >   
> >
> >> -Original Message-
> >> From: Peter Kovacs [mailto:pe...@apache.org]
> >> Sent: Monday, December 07, 2020 11:03 PM
> >> To: dev@openoffice.apache.org
> >> Subject: Re: [discussion] future embedded DB in AOO
> >>> Maybe one more thing: Is the problem database even important?
> >> We cannot build with Java 11 and up. Decisions have to be 
> made soon.
> >> Strategy has to be setup. A Roadmap would be great
> > Peter, I do not understand what that means in concrete terms.
> >
> > IF Java is a critical factor (I guess because of Oracle's 
> licensing policy) why is it less so for H2 or Derby than for HSQLDB?
> 
> No, I meant that building OpenOffice with Java 11 and later 
> causes the 
> build to break on hsqldb. So we need to talk
> 
> what we do. Current state is that we need to change the code 
> in order to 
> build on a later Java Version. That is what brought this 
> topic up. And 
> again I want to have a discussion on what we head out for. What is 
> needed. And I think this makes it a good time to collect all 
> opinions, 
> arguments and requirements.

Thank you for this declaration. The situation is therefore understandable to me.
 
> > Actually we should rather choose a database that works 
> without Java(?)
> >
> > Also: IF the Java question is urgent, why is it only for 
> Base? Doesn't belong then on the agenda anymore?
> 
> Where do I say it is urgent? 

I had understood "We cannot build with Java 11 and up." that way.

> This takes time. It is a good time to start this now.

yes, this is true


> What is your opinion on Java? Not that I want to start a general Java 
> discussion, but you are right they are connected.

As far as I know from Mathias Java is, in the long run, a problem because of 
the licensing policy of Oracle(*) and we have to find ways to free ourselves 
from this dependency.

Since these are rather long-term considerations, I can't say if we have to 
consider this already now for a decision regarding Base. 
It would tend to make sense, but searching for a database without Java 
dependency might collide somewhat with the question of multiplatform capability.

But please ... I am only answering your question here, I do not want to 
encourage you to expand the discussion.


(*)
if I understood it correctly, the problem is not technical in essence, but 
future Java versions should be subject to license fees, at least for business 
use (?)



Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Peter Kovacs]

On 08.12.20 09:27, Jörg Schmidt wrote:

-Original Message-
From: Keith N. McKenna [mailto:keith.mcke...@comcast.net]
Sent: Tuesday, December 08, 2020 3:49 AM
To: dev@openoffice.apache.org
Subject: Re: [discussion] future embedded DB in AOO
My first question has to be : Why are we still using such an
old version
of HSQLDB? As memory serves it is `1.8.0 and the latest release of
HSQLDB is 2.5.1.


I thought we had discussion on this, but I could not find them.

I will have later a second look. But this is a good thought. How much 
time will an upgrade bring us?


It will influence the roadmap for sure.



Second is why cannot we upgrade to HSQLDB 2.X.


The question is not if we can, the question is if it is worth it.

I would like to take an early opportunity to look beyond the immediate 
need of  keep things working.


I put on the question what alternative exists. Jörg brought up the 
Question how much Java do we want in future?



As a process engineer and not a programmer these are simple
questions I
need answers for to intelligently contribute to this
discussion. Thanks
all for your understanding.


All opinion and thoughts are welcome. I want to find out where we want 
to head with the embedded DB. All Ideas and reasoning can bring up good 
Views.


We can also discuss where we want to go with Base. The question is 
Connected. And Base needs some love, don't you think?



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Peter Kovacs]

On 08.12.20 09:14, Jörg Schmidt wrote:
  


-Original Message-
From: Peter Kovacs [mailto:pe...@apache.org]
Sent: Monday, December 07, 2020 11:03 PM
To: dev@openoffice.apache.org
Subject: Re: [discussion] future embedded DB in AOO

Maybe one more thing: Is the problem database even important?

We cannot build with Java 11 and up. Decisions have to be made soon.
Strategy has to be setup. A Roadmap would be great

Peter, I do not understand what that means in concrete terms.

IF Java is a critical factor (I guess because of Oracle's licensing policy) why 
is it less so for H2 or Derby than for HSQLDB?


No, I meant that building OpenOffice with Java 11 and later causes the 
build to break on hsqldb. So we need to talk


what we do. Current state is that we need to change the code in order to 
build on a later Java Version. That is what brought this topic up. And 
again I want to have a discussion on what we head out for. What is 
needed. And I think this makes it a good time to collect all opinions, 
arguments and requirements.



Actually we should rather choose a database that works without Java(?)

Also: IF the Java question is urgent, why is it only for Base? Doesn't belong 
then on the agenda anymore?


Where do I say it is urgent? I say we should take some time and consider 
our options. Making a sound decision.


This takes time. It is a good time to start this now.




I want to take
some time,
develop some strategy Maybe a roadmap.

IF it's a strategy we should probably talk about Java and not only about Base.
What is your opinion on Java? Not that I want to start a general Java 
discussion, but you are right they are connected.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

> -Original Message-
> From: Jörg Schmidt [mailto:joe...@j-m-schmidt.de] 
> Sent: Tuesday, December 08, 2020 9:14 AM
> To: dev@openoffice.apache.org
> Subject: RE: [discussion] future embedded DB in AOO
> 
>  
> [...]

Now I have to focus again:

Is the concrete problem Base or Java?

IF it is Java why are we even talking about replacing HSQLDB with Java-based 
databases?
Shouldn't our goal then be to find a database that is not based on Java?


Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

> -Original Message-
> From: Keith N. McKenna [mailto:keith.mcke...@comcast.net] 
> Sent: Tuesday, December 08, 2020 3:49 AM
> To: dev@openoffice.apache.org
> Subject: Re: [discussion] future embedded DB in AOO

> My first question has to be : Why are we still using such an 
> old version
> of HSQLDB? As memory serves it is `1.8.0 and the latest release of
> HSQLDB is 2.5.1.
> 
> Second is why cannot we upgrade to HSQLDB 2.X.
> 
> As a process engineer and not a programmer these are simple 
> questions I
> need answers for to intelligently contribute to this 
> discussion. Thanks
> all for your understanding.

indeed, one should not leave out these questions.



Jörg



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

 

> -Original Message-
> From: Peter Kovacs [mailto:pe...@apache.org] 
> Sent: Monday, December 07, 2020 11:03 PM
> To: dev@openoffice.apache.org
> Subject: Re: [discussion] future embedded DB in AOO

> > Maybe one more thing: Is the problem database even important?
> We cannot build with Java 11 and up. Decisions have to be made soon. 
> Strategy has to be setup. A Roadmap would be great

Peter, I do not understand what that means in concrete terms.

IF Java is a critical factor (I guess because of Oracle's licensing policy) why 
is it less so for H2 or Derby than for HSQLDB?
Actually we should rather choose a database that works without Java(?)

Also: IF the Java question is urgent, why is it only for Base? Doesn't belong 
then on the agenda anymore?

> I want to take 
> some time, 
> develop some strategy Maybe a roadmap. 

IF it's a strategy we should probably talk about Java and not only about Base.


greetings,
Jörg






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Keith N. McKenna]

On 12/7/2020 1:38 PM, Peter Kovacs wrote:
> Hi all,
> 
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).
> 
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
> 
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
> 
> What are your thoughts?
> 
> 
> All the Best
> 
> Peter

My first question has to be : Why are we still using such an old version
of HSQLDB? As memory serves it is `1.8.0 and the latest release of
HSQLDB is 2.5.1.

Second is why cannot we upgrade to HSQLDB 2.X.

As a process engineer and not a programmer these are simple questions I
need answers for to intelligently contribute to this discussion. Thanks
all for your understanding.

Regards
Keith.



signature.asc
Description: OpenPGP digital signature

Re: [discussion] future embedded DB in AOO

[Damjan Jovanovic]

On Mon, Dec 7, 2020 at 8:38 PM Peter Kovacs  wrote:

> Hi all,
>
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).
>
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
>
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
>
> What are your thoughts?
>
>
Whatever we do, we have to provide backward compatibility for HSQLDB.

I am more interested in something like Apache Calcite, which would let us
do SQL queries spanning multiple database backends, than in yet another
database backend.

SQLite is interesting because it's very widely used, runs on iPhone and
Android, is a single file, performs well, and is lightweight.

The hard part is getting the database to write into .ODB files instead of
what it natively uses?

Damjan

Re: [discussion] future embedded DB in AOO

[Peter Kovacs]

On 07.12.20 23:03, Jim Jagielski wrote:



On Dec 7, 2020, at 4:27 PM, Peter Kovacs  wrote:


On 07.12.20 20:48, Jim Jagielski wrote:

On Dec 7, 2020, at 1:38 PM, Peter Kovacs  wrote:

Hi all,

I would like to know how you guys feel we should move on with our base 
Database. Our current strategy is a small sized embedded DB using HSQLDB (BSD). 
There are 2 other options in the same weight class, that is H2 (EPL1 or MPL2) 
and Apache Derby (AL2).

Something like SQLLite (PublicDomain) could be technical interesting, but I 
think their licensing is not so appealing.

Is EPL1/MPL2 more appealing than SQLite's PD?

No not really. I am intimidated by the statements:

   Open-Source, not Open-Contribution

   SQLite is open-source, meaning that you can make as many copies of
   it as you want and do whatever you want with those copies, without
   limitation. But SQLite is not open-contribution. In order to keep
   SQLite in the public domain and ensure that the code does not become
   contaminated with proprietary or licensed content, the project does
   not accept patches from unknown persons.

   All of the code in SQLite is original, having been written
   specifically for use by SQLite. No code has been copied from unknown
   sources on the internet.

   Contributed Code

   In order to keep SQLite completely free and unencumbered by
   copyright, the project does not accept patches. If you would like to
   make a suggested change, and include a patch as a proof-of-concept,
   that would be great. However please do not be offended if we rewrite
   your patch from scratch.

Actually their Licensing is:

   Anyone is free to copy, modify, publish, use, compile, sell, or
   distribute the original SQLite code, either in source code form or
   as a compiled binary, for any purpose, commercial or non-commercial,
   and by any means.

Which is fine and works for us.

Also, let's look at https://www.apache.org/legal/resolved.html

Works in the public domain (or covered by a license treated similarly) may be 
included within Apache products. Attribution is required (in a similar fashion 
to the Category A list.

A work should be treated as being in the public domain when one of the 
following applies:

the work is covered by
the Creative Commons Public Domain Mark 
, or
a suitable dedication (to the public domain) by the authors; or


I think we can confidently affirm the 2nd bullet.

thanks Jim. I was not that sure about this point.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Jim Jagielski]

> On Dec 7, 2020, at 4:27 PM, Peter Kovacs  wrote:
> 
> 
> On 07.12.20 20:48, Jim Jagielski wrote:
>> 
>>> On Dec 7, 2020, at 1:38 PM, Peter Kovacs  wrote:
>>> 
>>> Hi all,
>>> 
>>> I would like to know how you guys feel we should move on with our base 
>>> Database. Our current strategy is a small sized embedded DB using HSQLDB 
>>> (BSD). There are 2 other options in the same weight class, that is H2 (EPL1 
>>> or MPL2) and Apache Derby (AL2).
>>> 
>>> Something like SQLLite (PublicDomain) could be technical interesting, but I 
>>> think their licensing is not so appealing.
>> Is EPL1/MPL2 more appealing than SQLite's PD?
> 
> No not really. I am intimidated by the statements:
> 
>   Open-Source, not Open-Contribution
> 
>   SQLite is open-source, meaning that you can make as many copies of
>   it as you want and do whatever you want with those copies, without
>   limitation. But SQLite is not open-contribution. In order to keep
>   SQLite in the public domain and ensure that the code does not become
>   contaminated with proprietary or licensed content, the project does
>   not accept patches from unknown persons.
> 
>   All of the code in SQLite is original, having been written
>   specifically for use by SQLite. No code has been copied from unknown
>   sources on the internet.
> 
>   Contributed Code
> 
>   In order to keep SQLite completely free and unencumbered by
>   copyright, the project does not accept patches. If you would like to
>   make a suggested change, and include a patch as a proof-of-concept,
>   that would be great. However please do not be offended if we rewrite
>   your patch from scratch.
> 
> Actually their Licensing is:
> 
>   Anyone is free to copy, modify, publish, use, compile, sell, or
>   distribute the original SQLite code, either in source code form or
>   as a compiled binary, for any purpose, commercial or non-commercial,
>   and by any means.
> 
> Which is fine and works for us.

Also, let's look at https://www.apache.org/legal/resolved.html

Works in the public domain (or covered by a license treated similarly) may be 
included within Apache products. Attribution is required (in a similar fashion 
to the Category A list. 

A work should be treated as being in the public domain when one of the 
following applies: 

the work is covered by 
the Creative Commons Public Domain Mark 
, or
a suitable dedication (to the public domain) by the authors; or 


I think we can confidently affirm the 2nd bullet. 

Re: [discussion] future embedded DB in AOO

[Peter Kovacs]

On 07.12.20 22:35, Jörg Schmidt wrote:

-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Monday, December 07, 2020 10:11 PM
To: dev
Subject: Re: [discussion] future embedded DB in AOO

I agree that eating our own dogfood and using Derby would be
the "better" path to take; plus it is relatively small while
at the same time being quite powerful and compliant.

As already written: I don't know both systems and I only made my statement 
based on the information I found on Wikipedia.
If Mechtilde (and others) have real experience with one of the two databases, 
this would have more weight.

Maybe one more thing: Is the problem database even important?
We cannot build with Java 11 and up. Decisions have to be made soon. 
Strategy has to be setup. A Roadmap would be great

LO, for example, has much more manpower than we do, and yet Firebird in LO 
still seems to me to be a construction site, because actually everyone advises 
me to stay with HSQLDB (as far as an embedded DB is concerned).
More Manpower does not mean they invest it into Base. So I would not 
judge on our strength or weakness.

AOO should avoid getting into the same situation, because invested work that 
ultimately creates no benefit for the user is badly invested.
That statement is true but incomplete. We need to take into account how 
much work it is for us to maintain an embedded DB. The DB eats our 
resources. A good choice can make a difference in the future.

Yes, it is a very soft argument to warn not to start at all, because you are 
afraid, that you can not make it.
But many other questions seem to me to be more urgent, e.g. the currently 
detected problems with Big Sur (maybe other MacOS versions?)


Well, there are always more important topics. I want to take some time, 
develop some strategy Maybe a roadmap. Maybe it is a good Idea to check 
the options a bit. Maybe even to have something to talk about on next 
FOSDEM.


We have a Room and a Deadline and no talks yet. :)

I just want to know how everyone feels on this topic, since we need to 
make a decision someday.





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com] 
> Sent: Monday, December 07, 2020 10:11 PM
> To: dev
> Subject: Re: [discussion] future embedded DB in AOO
> 
> I agree that eating our own dogfood and using Derby would be 
> the "better" path to take; plus it is relatively small while 
> at the same time being quite powerful and compliant. 

As already written: I don't know both systems and I only made my statement 
based on the information I found on Wikipedia.
If Mechtilde (and others) have real experience with one of the two databases, 
this would have more weight.

Maybe one more thing: Is the problem database even important?
LO, for example, has much more manpower than we do, and yet Firebird in LO 
still seems to me to be a construction site, because actually everyone advises 
me to stay with HSQLDB (as far as an embedded DB is concerned).
AOO should avoid getting into the same situation, because invested work that 
ultimately creates no benefit for the user is badly invested.

Yes, it is a very soft argument to warn not to start at all, because you are 
afraid, that you can not make it.
But many other questions seem to me to be more urgent, e.g. the currently 
detected problems with Big Sur (maybe other MacOS versions?)   



Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Peter Kovacs]

On 07.12.20 20:48, Jim Jagielski wrote:



On Dec 7, 2020, at 1:38 PM, Peter Kovacs  wrote:

Hi all,

I would like to know how you guys feel we should move on with our base 
Database. Our current strategy is a small sized embedded DB using HSQLDB (BSD). 
There are 2 other options in the same weight class, that is H2 (EPL1 or MPL2) 
and Apache Derby (AL2).

Something like SQLLite (PublicDomain) could be technical interesting, but I 
think their licensing is not so appealing.

Is EPL1/MPL2 more appealing than SQLite's PD?


No not really. I am intimidated by the statements:

   Open-Source, not Open-Contribution

   SQLite is open-source, meaning that you can make as many copies of
   it as you want and do whatever you want with those copies, without
   limitation. But SQLite is not open-contribution. In order to keep
   SQLite in the public domain and ensure that the code does not become
   contaminated with proprietary or licensed content, the project does
   not accept patches from unknown persons.

   All of the code in SQLite is original, having been written
   specifically for use by SQLite. No code has been copied from unknown
   sources on the internet.

   Contributed Code

   In order to keep SQLite completely free and unencumbered by
   copyright, the project does not accept patches. If you would like to
   make a suggested change, and include a patch as a proof-of-concept,
   that would be great. However please do not be offended if we rewrite
   your patch from scratch.

Actually their Licensing is:

   Anyone is free to copy, modify, publish, use, compile, sell, or
   distribute the original SQLite code, either in source code form or
   as a compiled binary, for any purpose, commercial or non-commercial,
   and by any means.

Which is fine and works for us.

Re: [discussion] future embedded DB in AOO

[Jim Jagielski]

> On Dec 7, 2020, at 2:46 PM, Jörg Schmidt  wrote:
> 
> With both databases, however, Java bothers me - or have we given up the 
> intention of making AOO less dependent on Java?
> (yes, of course this is a very long-term question)

But still a good one... personally, SQlite seems like a better, more strategic, 
option with that in mind.

Re: [discussion] future embedded DB in AOO

[Jim Jagielski]

I agree that eating our own dogfood and using Derby would be the "better" path 
to take; plus it is relatively small while at the same time being quite 
powerful and compliant. 

> On Dec 7, 2020, at 2:46 PM, Jörg Schmidt  wrote:
> 
> Hello, 
> 
>> -Original Message-
>> From: Peter Kovacs [mailto:pe...@apache.org] 
>> Sent: Monday, December 07, 2020 7:38 PM
>> To: dev@openoffice.apache.org
>> Subject: [discussion] future embedded DB in AOO
>> 
>> Hi all,
>> 
>> I would like to know how you guys feel we should move on with 
>> our base 
>> Database. ...
> 
> There is no compelling reason for us to join LO on the database issue, it may 
> even be strategically smart not to.
> 
> I know neither H2 nor Apache Derby and have only briefly checked Wikipedia 
> and if these two were available I would be in favour of Derby, because:
> -obviously better support for SQL
> -maybe, due to the longer history, the more mature system
> -apparently better encryption features
> -Apache Project
> 
> But maybe there is an argument for H2:
> this project seems to be, in essence, driven by a single developer, most 
> likely the one who would welcome H2 to become more known when we use it in 
> AOO and would be willing to coordinate the development of H2 with us, so that 
> H2 adapts to the requirements of AOO in the best possible way. 
> 
> 
> With both databases, however, Java bothers me - or have we given up the 
> intention of making AOO less dependent on Java?
> (yes, of course this is a very long-term question)
> 
> 
> 
> 
> greetings,
> Jörg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
> <mailto:dev-unsubscr...@openoffice.apache.org>
> For additional commands, e-mail: dev-h...@openoffice.apache.org 
> <mailto:dev-h...@openoffice.apache.org>

[discussion] future embedded DB in AOO

[Mechtilde]

Hello Peter,

Am 07.12.20 um 19:38 schrieb Peter Kovacs:
> Hi all,
> 
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).

I prefer H2by several reasens:
1. H2 is the continued deelopment of HSQLDB
2. H2 is also used in other applications like Hibiscus (and JVerein ;-))
3. I know also some properity software which use it as an embedded DB

kind regards

Mechtilde

> 
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
> 
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
> 
> What are your thoughts?
> 
> 
> All the Best
> 
> Peter
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F





OpenPGP_signature
Description: OpenPGP digital signature

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

Hello, 

> -Original Message-
> From: Mechtilde [mailto:o...@mechtilde.de] 
> Sent: Monday, December 07, 2020 8:11 PM
> To: dev@openoffice.apache.org
> Subject: Re: [discussion] future embedded DB in AOO
> 
> Hello Peter,
> 
> Am 07.12.20 um 19:38 schrieb Peter Kovacs:
> > Hi all,
> > 
> > I would like to know how you guys feel we should move on 
> with our base
> > Database. Our current strategy is a small sized embedded DB 
> using HSQLDB
> > (BSD). There are 2 other options in the same weight class, 
> that is H2
> > (EPL1 or MPL2) and Apache Derby (AL2).
> 
> I prefer H2by several reasens:
> 1. H2 is the continued deelopment of HSQLDB
> 2. H2 is also used in other applications like Hibiscus (and 
> JVerein ;-))
> 3. I know also some proprietary software which use it as an 
> embedded DB

If I read wikipedia the SQL support seems to be worse (in the sense of 
incomplete) for H2 than for Derby. 
Is there anything more to say about this? (Maybe the impression I get from 
wikipedia is deceptive?)


greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Jim Jagielski]

> On Dec 7, 2020, at 1:38 PM, Peter Kovacs  wrote:
> 
> Hi all,
> 
> I would like to know how you guys feel we should move on with our base 
> Database. Our current strategy is a small sized embedded DB using HSQLDB 
> (BSD). There are 2 other options in the same weight class, that is H2 (EPL1 
> or MPL2) and Apache Derby (AL2).
> 
> Something like SQLLite (PublicDomain) could be technical interesting, but I 
> think their licensing is not so appealing.

Is EPL1/MPL2 more appealing than SQLite's PD?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [discussion] future embedded DB in AOO

[Jörg Schmidt]

Hello, 

> -Original Message-
> From: Peter Kovacs [mailto:pe...@apache.org] 
> Sent: Monday, December 07, 2020 7:38 PM
> To: dev@openoffice.apache.org
> Subject: [discussion] future embedded DB in AOO
> 
> Hi all,
> 
> I would like to know how you guys feel we should move on with 
> our base 
> Database. ...

There is no compelling reason for us to join LO on the database issue, it may 
even be strategically smart not to.

I know neither H2 nor Apache Derby and have only briefly checked Wikipedia and 
if these two were available I would be in favour of Derby, because:
-obviously better support for SQL
-maybe, due to the longer history, the more mature system
-apparently better encryption features
-Apache Project

But maybe there is an argument for H2:
this project seems to be, in essence, driven by a single developer, most likely 
the one who would welcome H2 to become more known when we use it in AOO and 
would be willing to coordinate the development of H2 with us, so that H2 adapts 
to the requirements of AOO in the best possible way. 


With both databases, however, Java bothers me - or have we given up the 
intention of making AOO less dependent on Java?
(yes, of course this is a very long-term question)




greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [discussion] future embedded DB in AOO

[Mechtilde]

Hello Peter,

Am 07.12.20 um 19:38 schrieb Peter Kovacs:
> Hi all,
> 
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).

I prefer H2by several reasens:
1. H2 is the continued deelopment of HSQLDB
2. H2 is also used in other applications like Hibiscus (and JVerein ;-))
3. I know also some proprietary software which use it as an embedded DB

kind regards

Mechtilde

> 
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
> 
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
> 
> What are your thoughts?
> 
> 
> All the Best
> 
> Peter
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

[discussion] future embedded DB in AOO

[Peter Kovacs]

Hi all,

I would like to know how you guys feel we should move on with our base 
Database. Our current strategy is a small sized embedded DB using HSQLDB 
(BSD). There are 2 other options in the same weight class, that is H2 
(EPL1 or MPL2) and Apache Derby (AL2).


Something like SQLLite (PublicDomain) could be technical interesting, 
but I think their licensing is not so appealing.


We could also consider firebird (MPL) like LO, but I have the impression 
that this is not a lightweight DB, but featurerich. And I wonder if this 
is really something we should provide. I would rather develop a way to 
make it easy to switch the DB when a Project grows.


What are your thoughts?


All the Best

Peter


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org