Re: Updating Java libraries

[Michael Lam]

On 02/13/2013 12:48 PM, Fred Ollinger wrote:

Relying on jars, IMHO, is not bad, but it depends on your goals.

The point of compiling from source is that it's a first step to
actually being a developer which is why I do it. Compiling problems
aren't problems for us new developers they are puzzles to solve to
help people out.

If there are changes needed to the jars, we need to recompile. For a
build where I don't modify the jar, I'd prefer to just fetch it b/c
it's way faster. Also, where does compiling from source end. That is,
we all rely on someone else's compiling some of our software (unless
our name is Theo, I guess). :)

Fred

On Tue, Feb 12, 2013 at 7:28 PM, Ariel Constenla-Haile
 wrote:

Hi Michael,

On Tue, Feb 12, 2013 at 09:59:02PM -0500, Michael Lam wrote:

On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote:

On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote:

I have updated the external_deps.lst with the updated hsqldb
information. If someone can give me some pointer into how to just
retrieve the jar instead of the source

You don't retrieve precompiled stuff. The logic is:

a) don't include the dependency at all

b) include the dependency

b.1) build it from source

b.2) use the precompiled version in the system (this switch is only for
external packagers, the builds are release with no system [configurable]
dependencies).


Regards

I am still a little confused. Obviously it is possible to build from
source but as a lot of email on the list have shown it could cause
issues with the build that is not directly related to the AOO code.
Why not just retrieve the jar so the build is inclusive?

I don't know what motivated these rules, but I guess it was something in
the lines of having control about what is being compiled and how it is
being compiled (the use of the compiler, the Java base line, etc.).

35 million of downloads are worth not relaying on a jar built by someone
else and, instead, build it from sources.



I am used to retrieving compiled jars on the projects I worked on, in
Java there is maven and ivy to retrieve specific version of the jar
that the project is tested on along with the dependencies.

But it is still trusting in a binary built by someone else. Every
project is free to trust or build from sources. Historically, OpenOffice
builds from external sources and includes these binaries in its
releases, it has no external dependencies (other than the system
libraries). The configure switches that allow building with system
libraries/jars are only supported on *nix, and even there they are not
relaying on a jar built by someone else: Linux distributions, for
example, build all their jars; why do they build all by themselves
instead of fetching compiled jars? I've no idea, but I guess they follow
the same criteria mentioned above (as a Linux user you can use Maven in
your projects, but it won't modify the system's jars).


Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Thank you for the explanation. For now I will stick to the current setup 
and make couple more changes but I would like my idea to be consider in 
the future. It is true for most long running system that some of the why 
certain decisions were made is lost and I am quite sure there were/are 
legitimate reasons. It would just helpful to know instead of doing the 
same thing just because. As far as trust, that is interesting in this 
context since I would be fetching from the source and given that the 
project is using the third party code in such a integral way that I 
would think the trust is implicit.

Re: Updating Java libraries

[Fred Ollinger]

Relying on jars, IMHO, is not bad, but it depends on your goals.

The point of compiling from source is that it's a first step to
actually being a developer which is why I do it. Compiling problems
aren't problems for us new developers they are puzzles to solve to
help people out.

If there are changes needed to the jars, we need to recompile. For a
build where I don't modify the jar, I'd prefer to just fetch it b/c
it's way faster. Also, where does compiling from source end. That is,
we all rely on someone else's compiling some of our software (unless
our name is Theo, I guess). :)

Fred

On Tue, Feb 12, 2013 at 7:28 PM, Ariel Constenla-Haile
 wrote:
> Hi Michael,
>
> On Tue, Feb 12, 2013 at 09:59:02PM -0500, Michael Lam wrote:
>> On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote:
>> >On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote:
>> >>I have updated the external_deps.lst with the updated hsqldb
>> >>information. If someone can give me some pointer into how to just
>> >>retrieve the jar instead of the source
>> >You don't retrieve precompiled stuff. The logic is:
>> >
>> >a) don't include the dependency at all
>> >
>> >b) include the dependency
>> >
>> >b.1) build it from source
>> >
>> >b.2) use the precompiled version in the system (this switch is only for
>> >external packagers, the builds are release with no system [configurable]
>> >dependencies).
>> >
>> >
>> >Regards
>> I am still a little confused. Obviously it is possible to build from
>> source but as a lot of email on the list have shown it could cause
>> issues with the build that is not directly related to the AOO code.
>> Why not just retrieve the jar so the build is inclusive?
>
> I don't know what motivated these rules, but I guess it was something in
> the lines of having control about what is being compiled and how it is
> being compiled (the use of the compiler, the Java base line, etc.).
>
> 35 million of downloads are worth not relaying on a jar built by someone
> else and, instead, build it from sources.
>
>
>> I am used to retrieving compiled jars on the projects I worked on, in
>> Java there is maven and ivy to retrieve specific version of the jar
>> that the project is tested on along with the dependencies.
>
> But it is still trusting in a binary built by someone else. Every
> project is free to trust or build from sources. Historically, OpenOffice
> builds from external sources and includes these binaries in its
> releases, it has no external dependencies (other than the system
> libraries). The configure switches that allow building with system
> libraries/jars are only supported on *nix, and even there they are not
> relaying on a jar built by someone else: Linux distributions, for
> example, build all their jars; why do they build all by themselves
> instead of fetching compiled jars? I've no idea, but I guess they follow
> the same criteria mentioned above (as a Linux user you can use Maven in
> your projects, but it won't modify the system's jars).
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina

Re: Updating Java libraries

[Ariel Constenla-Haile]

Hi Michael,

On Tue, Feb 12, 2013 at 09:59:02PM -0500, Michael Lam wrote:
> On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote:
> >On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote:
> >>I have updated the external_deps.lst with the updated hsqldb
> >>information. If someone can give me some pointer into how to just
> >>retrieve the jar instead of the source
> >You don't retrieve precompiled stuff. The logic is:
> >
> >a) don't include the dependency at all
> >
> >b) include the dependency
> >
> >b.1) build it from source
> >
> >b.2) use the precompiled version in the system (this switch is only for
> >external packagers, the builds are release with no system [configurable]
> >dependencies).
> >
> >
> >Regards
> I am still a little confused. Obviously it is possible to build from
> source but as a lot of email on the list have shown it could cause
> issues with the build that is not directly related to the AOO code.
> Why not just retrieve the jar so the build is inclusive? 

I don't know what motivated these rules, but I guess it was something in
the lines of having control about what is being compiled and how it is
being compiled (the use of the compiler, the Java base line, etc.).

35 million of downloads are worth not relaying on a jar built by someone
else and, instead, build it from sources.


> I am used to retrieving compiled jars on the projects I worked on, in
> Java there is maven and ivy to retrieve specific version of the jar
> that the project is tested on along with the dependencies.

But it is still trusting in a binary built by someone else. Every
project is free to trust or build from sources. Historically, OpenOffice
builds from external sources and includes these binaries in its
releases, it has no external dependencies (other than the system
libraries). The configure switches that allow building with system
libraries/jars are only supported on *nix, and even there they are not
relaying on a jar built by someone else: Linux distributions, for
example, build all their jars; why do they build all by themselves
instead of fetching compiled jars? I've no idea, but I guess they follow
the same criteria mentioned above (as a Linux user you can use Maven in
your projects, but it won't modify the system's jars).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgprnEyK5tGGc.pgp
Description: PGP signature

Re: Updating Java libraries

[Michael Lam]

On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote:

On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote:

I have updated the external_deps.lst with the updated hsqldb
information. If someone can give me some pointer into how to just
retrieve the jar instead of the source

You don't retrieve precompiled stuff. The logic is:

a) don't include the dependency at all

b) include the dependency

b.1) build it from source

b.2) use the precompiled version in the system (this switch is only for
external packagers, the builds are release with no system [configurable]
dependencies).


Regards
I am still a little confused. Obviously it is possible to build from 
source but as a lot of email on the list have shown it could cause 
issues with the build that is not directly related to the AOO code. Why 
not just retrieve the jar so the build is inclusive? Wouldn't leaving it 
out allow someone to build with a version that is not fully tested? I am 
new to this type of development, so any clarification would be most 
helpful. I am used to retrieving compiled jars on the projects I worked 
on, in Java there is maven and ivy to retrieve specific version of the 
jar that the project is tested on along with the dependencies.

Re: Updating Java libraries

[Herbert Dürr]

On 2013/02/11 8:06 PM, Michael Lam wrote:

It is partially to address the JDK issue but there have been
improvements in HSQLDB for both performance and conformance that would
be helpful which is why I lean more towards updating to the latest
rather than patching the existing.


Absolutely! The JDK/JRE issue alone proves that an update is overdue.

I just wanted to answer your question why in the AOO codebase external 
dependencies are sometimes patched instead of being simply upgraded to 
the latest released version.



I understand it would be difficult to
constantly update to the latest release of a dependent project both in a
quality and release standpoint. With adequate planning and testing, the
code should also allow for an update to the latest without too many
gotchas.


Thanks again for working on this!

Herbert

Re: Updating Java libraries

[Ariel Constenla-Haile]

On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote:
> I have updated the external_deps.lst with the updated hsqldb
> information. If someone can give me some pointer into how to just
> retrieve the jar instead of the source

You don't retrieve precompiled stuff. The logic is:

a) don't include the dependency at all

b) include the dependency

b.1) build it from source

b.2) use the precompiled version in the system (this switch is only for
external packagers, the builds are release with no system [configurable]
dependencies).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpGTvDryoQ0D.pgp
Description: PGP signature

Re: Updating Java libraries

[Michael Lam]

I am guessing my next steps would be looking into updating the build to 
pull the jar?

Better use the mechanism provided by main/external_deps.lst

Herbert




I have updated the external_deps.lst with the updated hsqldb 
information. If someone can give me some pointer into how to just 
retrieve the jar instead of the source, I can look into simplifying the 
build a little bit. I am thinking I just need to emulate 
--with-hsqldb-jar and the rest of the build does not need to be touch, 
any pointer along that line would also be helpful.


Michael

Re: Updating Java libraries

[Michael Lam]

On 02/11/2013 05:43 PM, Kay Schenk wrote:



On 02/11/2013 02:19 PM, Fred Ollinger wrote:

OK, I won't build with java6 anymore then.

Fred


More than likely no need unless certain sites/people refuse to update 
to java 1.7. I really can't imagine who that would be at this point.




On Mon, Feb 11, 2013 at 12:30 PM, Fernando Cassia  
wrote:
On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger  
wrote:



Haha, I don't know. I could be wrong.



OpenJDK 7 is the current version, OpenJDK 8 is coming along nicely.

OpenJDK 6 is the past. Yes, there' s been some RedHat volunteers saying
they' ll keep releasing OpenJDK 6 updates and security fixes, but 
from a
developers'  perspective it' s as unattractive as some .Net 
developer still
using the Net 1.0 APIs... or a Java developer still using JDK 1.4 
for that

matter.

Ubuntu: OpenJDK 7
http://packages.ubuntu.com/oneiric/openjdk-7-jdk

Fedora 18: OpenJDK 7
http://pkgs.org/download/java-1.7.0-openjdk

SUSE: OpenJDK 7
http://software.opensuse.org/package/java-1_7_0-openjdk

Debian: OpenJDK 7
http://packages.debian.org/sid/openjdk-7-jre

ArchLinux: OpenJDK 7
https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/

So, again: "we should also respect that many distros are probably 
going to

ship java 6 for a while." = SciFi ?

FC



--
During times of Universal Deceit, telling the truth becomes a 
revolutionary

act
Durante épocas de Engaño Universal, decir la verdad se convierte en 
un Acto

Revolucionario
- George Orwell


Using a newer JDK is fine, just need to make sure the target version is 
correct. I am not sure what version is the minimum, I would guess 1.5. 
Need to be careful not to use features that is not supported by the 
minimum version. Let's not limit to just Linux distros. There is 
probably a good portion of users on Windows and not everybody is on top 
of their updates.


Michael

Re: Updating Java libraries

[Kay Schenk]

On 02/11/2013 02:19 PM, Fred Ollinger wrote:

OK, I won't build with java6 anymore then.

Fred


More than likely no need unless certain sites/people refuse to update to 
java 1.7. I really can't imagine who that would be at this point.




On Mon, Feb 11, 2013 at 12:30 PM, Fernando Cassia  wrote:

On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger  wrote:


Haha, I don't know. I could be wrong.



OpenJDK 7 is the current version, OpenJDK 8 is coming along nicely.

OpenJDK 6 is the past. Yes, there' s been some RedHat volunteers saying
they' ll keep releasing OpenJDK 6 updates and security fixes, but from a
developers'  perspective it' s as unattractive as some .Net developer still
using the Net 1.0 APIs... or a Java developer still using JDK 1.4 for that
matter.

Ubuntu: OpenJDK 7
http://packages.ubuntu.com/oneiric/openjdk-7-jdk

Fedora 18: OpenJDK 7
http://pkgs.org/download/java-1.7.0-openjdk

SUSE: OpenJDK 7
http://software.opensuse.org/package/java-1_7_0-openjdk

Debian: OpenJDK 7
http://packages.debian.org/sid/openjdk-7-jre

ArchLinux: OpenJDK 7
https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/

So, again: "we should also respect that many distros are probably going to
ship java 6 for a while." = SciFi ?

FC



--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell


--

MzK

"A great deal of talent is lost to the world
  for want of a little courage."
 -- Sydney Smith

Re: Updating Java libraries

[Fernando Cassia]

On Mon, Feb 11, 2013 at 5:19 PM, Fred Ollinger  wrote:

> OK, I won't build with java6 anymore then.


don' t get me wrong, I don' t want to influence your decissions one way or
the other.
For sure there's a lot of openjdk 6 installed out there.

My point was that, going forward, most distros will have openjdk7.

FC


-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell

Re: Updating Java libraries

[Fred Ollinger]

OK, I won't build with java6 anymore then.

Fred

On Mon, Feb 11, 2013 at 12:30 PM, Fernando Cassia  wrote:
> On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger  wrote:
>
>> Haha, I don't know. I could be wrong.
>
>
> OpenJDK 7 is the current version, OpenJDK 8 is coming along nicely.
>
> OpenJDK 6 is the past. Yes, there' s been some RedHat volunteers saying
> they' ll keep releasing OpenJDK 6 updates and security fixes, but from a
> developers'  perspective it' s as unattractive as some .Net developer still
> using the Net 1.0 APIs... or a Java developer still using JDK 1.4 for that
> matter.
>
> Ubuntu: OpenJDK 7
> http://packages.ubuntu.com/oneiric/openjdk-7-jdk
>
> Fedora 18: OpenJDK 7
> http://pkgs.org/download/java-1.7.0-openjdk
>
> SUSE: OpenJDK 7
> http://software.opensuse.org/package/java-1_7_0-openjdk
>
> Debian: OpenJDK 7
> http://packages.debian.org/sid/openjdk-7-jre
>
> ArchLinux: OpenJDK 7
> https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/
>
> So, again: "we should also respect that many distros are probably going to
> ship java 6 for a while." = SciFi ?
>
> FC
>
>
>
> --
> During times of Universal Deceit, telling the truth becomes a revolutionary
> act
> Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
> Revolucionario
> - George Orwell

Re: Updating Java libraries

[Fernando Cassia]

On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger  wrote:

> Haha, I don't know. I could be wrong.


OpenJDK 7 is the current version, OpenJDK 8 is coming along nicely.

OpenJDK 6 is the past. Yes, there' s been some RedHat volunteers saying
they' ll keep releasing OpenJDK 6 updates and security fixes, but from a
developers'  perspective it' s as unattractive as some .Net developer still
using the Net 1.0 APIs... or a Java developer still using JDK 1.4 for that
matter.

Ubuntu: OpenJDK 7
http://packages.ubuntu.com/oneiric/openjdk-7-jdk

Fedora 18: OpenJDK 7
http://pkgs.org/download/java-1.7.0-openjdk

SUSE: OpenJDK 7
http://software.opensuse.org/package/java-1_7_0-openjdk

Debian: OpenJDK 7
http://packages.debian.org/sid/openjdk-7-jre

ArchLinux: OpenJDK 7
https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/

So, again: "we should also respect that many distros are probably going to
ship java 6 for a while." = SciFi ?

FC



-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell

Re: Updating Java libraries

[Fred Ollinger]

Haha, I don't know. I could be wrong.

I'm not trying to start a debate, but I'm just trying help to get
things working on as many current distros as possible.

Best Wishes,

Fred

On Mon, Feb 11, 2013 at 12:08 PM, Fernando Cassia  wrote:
> On Mon, Feb 11, 2013 at 2:16 PM, Fred Ollinger  wrote:
>
>> but we should also
>> respect that many distros are probably going to ship java 6 for a
>> while.
>>
>
> for example?
>
> FC

Re: Updating Java libraries

[Fernando Cassia]

On Mon, Feb 11, 2013 at 2:16 PM, Fred Ollinger  wrote:

> but we should also
> respect that many distros are probably going to ship java 6 for a
> while.
>

for example?

FC

Re: Updating Java libraries

[Fernando Cassia]

On Mon, Feb 11, 2013 at 2:06 PM, Michael Lam  wrote:

> It is partially to address the JDK issue but there have been improvements
> in HSQLDB for both performance and conformance that would be helpful which
> is why I lean more towards updating to the latest rather than patching the
> existing


+1
fwiw
FC

Re: Updating Java libraries

[Fred Ollinger]

I'll help with testing java 6 and java 7 from Oracle.

I vote for keeping up with latest and greatest, but we should also
respect that many distros are probably going to ship java 6 for a
while.

Thus, we should probably work with both then officially deprecated
java6 when it's time.

Fred

On Mon, Feb 11, 2013 at 11:06 AM, Michael Lam  wrote:
> On 02/11/2013 01:16 PM, Kay Schenk wrote:
>>
>> On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr  wrote:
>>
>>> Hi Michael,
>>>
>>>
>>> On 11.02.2013 17:21, Michael Lam wrote:
>>>
 I have successfully test hsqldb-2.2.9 against the following 4 issues and
 it is functioning correctly:

 https://issues.apache.org/ooo/**show_bug.cgi?id=96823

 https://issues.apache.org/ooo/**show_bug.cgi?id=103528

 https://issues.apache.org/ooo/**show_bug.cgi?id=104901

 https://issues.apache.org/ooo/**show_bug.cgi?id=97032

>>> Thanks a lot for investigating this!
>>
>>
>> yes, great news!
>>
>>
>>>
>>>   and I have looked at


 http://hg.services.openoffice.**org/cws/hsqldb19/

 Unless I am looking at this wrong, many of the changes are not related
 to hsqldb19 and it is already in the latest revision. As for the hsqldb
 specific, the patches does not apply to 2.2.9. As far as patches,
 wouldn't it be better to report upstream and provide the patch instead
 of just patching within the build?

>>> Definitely.
>>>
>>> In a linux distribution or a project such as ours with so many external
>>> dependencies there are good reasons not to always use the latest version
>>> of
>>> each component: That could easily result in endless churn and prevent
>>> releases. So backporting fixes is an alternative that should is often
>>> preferable. I don't know the background of the issues mentioned above
>>> that
>>> were fixed for HSQLDB but maybe they were such backports of fixes?
>>
>>
>> I thought the main reason for investigating the HSQLDB upgrade/change was
>> due to issues between java 6 and 7? we have some other patches submitted
>> to
>> help with that also. I could be wrong about this though.
>>
>>
>>
>>>
>>>   There are also checks within the code

 to specifically check for version 1.8.x, not sure  wouldn't it be better
 to enforce on configure/bootstrap? The current way seem to require a lot
 more work to update dependencies and the with-system-hsqldb for
 configure provides no warning.

>>> Using configure for checking this and cleaning up checks for obsoleted
>>> versions is a good plan. Please go ahead.
>>>
>>>
>>>   I will take a look at the open issues and see if it is resolved with
>>> the

 new version.

 I am guessing my next steps would be looking into updating the build to
 pull the jar?

>>> Better use the mechanism provided by main/external_deps.lst
>>>
>>> Herbert
>>>
>>
>>
> It is partially to address the JDK issue but there have been improvements in
> HSQLDB for both performance and conformance that would be helpful which is
> why I lean more towards updating to the latest rather than patching the
> existing. I understand it would be difficult to constantly update to the
> latest release of a dependent project both in a quality and release
> standpoint. With adequate planning and testing, the code should also allow
> for an update to the latest without too many gotchas.

Re: Updating Java libraries

[Michael Lam]

On 02/11/2013 01:16 PM, Kay Schenk wrote:

On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr  wrote:


Hi Michael,


On 11.02.2013 17:21, Michael Lam wrote:


I have successfully test hsqldb-2.2.9 against the following 4 issues and
it is functioning correctly:
https://issues.apache.org/ooo/**show_bug.cgi?id=96823
https://issues.apache.org/ooo/**show_bug.cgi?id=103528
https://issues.apache.org/ooo/**show_bug.cgi?id=104901
https://issues.apache.org/ooo/**show_bug.cgi?id=97032


Thanks a lot for investigating this!


yes, great news!




  and I have looked at

http://hg.services.openoffice.**org/cws/hsqldb19/

Unless I am looking at this wrong, many of the changes are not related
to hsqldb19 and it is already in the latest revision. As for the hsqldb
specific, the patches does not apply to 2.2.9. As far as patches,
wouldn't it be better to report upstream and provide the patch instead
of just patching within the build?


Definitely.

In a linux distribution or a project such as ours with so many external
dependencies there are good reasons not to always use the latest version of
each component: That could easily result in endless churn and prevent
releases. So backporting fixes is an alternative that should is often
preferable. I don't know the background of the issues mentioned above that
were fixed for HSQLDB but maybe they were such backports of fixes?


I thought the main reason for investigating the HSQLDB upgrade/change was
due to issues between java 6 and 7? we have some other patches submitted to
help with that also. I could be wrong about this though.





  There are also checks within the code

to specifically check for version 1.8.x, not sure  wouldn't it be better
to enforce on configure/bootstrap? The current way seem to require a lot
more work to update dependencies and the with-system-hsqldb for
configure provides no warning.


Using configure for checking this and cleaning up checks for obsoleted
versions is a good plan. Please go ahead.


  I will take a look at the open issues and see if it is resolved with the

new version.

I am guessing my next steps would be looking into updating the build to
pull the jar?


Better use the mechanism provided by main/external_deps.lst

Herbert




It is partially to address the JDK issue but there have been 
improvements in HSQLDB for both performance and conformance that would 
be helpful which is why I lean more towards updating to the latest 
rather than patching the existing. I understand it would be difficult to 
constantly update to the latest release of a dependent project both in a 
quality and release standpoint. With adequate planning and testing, the 
code should also allow for an update to the latest without too many gotchas.

Re: Updating Java libraries

[Kay Schenk]

On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr  wrote:

> Hi Michael,
>
>
> On 11.02.2013 17:21, Michael Lam wrote:
>
>> I have successfully test hsqldb-2.2.9 against the following 4 issues and
>> it is functioning correctly:
>> https://issues.apache.org/ooo/**show_bug.cgi?id=96823
>> https://issues.apache.org/ooo/**show_bug.cgi?id=103528
>> https://issues.apache.org/ooo/**show_bug.cgi?id=104901
>> https://issues.apache.org/ooo/**show_bug.cgi?id=97032
>>
>
> Thanks a lot for investigating this!


yes, great news!


>
>
>  and I have looked at
>>
>> http://hg.services.openoffice.**org/cws/hsqldb19/
>>
>> Unless I am looking at this wrong, many of the changes are not related
>> to hsqldb19 and it is already in the latest revision. As for the hsqldb
>> specific, the patches does not apply to 2.2.9. As far as patches,
>> wouldn't it be better to report upstream and provide the patch instead
>> of just patching within the build?
>>
>
> Definitely.
>
> In a linux distribution or a project such as ours with so many external
> dependencies there are good reasons not to always use the latest version of
> each component: That could easily result in endless churn and prevent
> releases. So backporting fixes is an alternative that should is often
> preferable. I don't know the background of the issues mentioned above that
> were fixed for HSQLDB but maybe they were such backports of fixes?


I thought the main reason for investigating the HSQLDB upgrade/change was
due to issues between java 6 and 7? we have some other patches submitted to
help with that also. I could be wrong about this though.



>
>
>  There are also checks within the code
>> to specifically check for version 1.8.x, not sure  wouldn't it be better
>> to enforce on configure/bootstrap? The current way seem to require a lot
>> more work to update dependencies and the with-system-hsqldb for
>> configure provides no warning.
>>
>
> Using configure for checking this and cleaning up checks for obsoleted
> versions is a good plan. Please go ahead.
>
>
>  I will take a look at the open issues and see if it is resolved with the
>> new version.
>>
>> I am guessing my next steps would be looking into updating the build to
>> pull the jar?
>>
>
> Better use the mechanism provided by main/external_deps.lst
>
> Herbert
>



-- 

MzK

"A great deal of talent is lost to the world
  for want of a little courage."
 -- Sydney Smith

Re: Updating Java libraries

[Herbert Duerr]

Hi Michael,

On 11.02.2013 17:21, Michael Lam wrote:

I have successfully test hsqldb-2.2.9 against the following 4 issues and
it is functioning correctly:
https://issues.apache.org/ooo/show_bug.cgi?id=96823
https://issues.apache.org/ooo/show_bug.cgi?id=103528
https://issues.apache.org/ooo/show_bug.cgi?id=104901
https://issues.apache.org/ooo/show_bug.cgi?id=97032


Thanks a lot for investigating this!


and I have looked at

http://hg.services.openoffice.org/cws/hsqldb19/

Unless I am looking at this wrong, many of the changes are not related
to hsqldb19 and it is already in the latest revision. As for the hsqldb
specific, the patches does not apply to 2.2.9. As far as patches,
wouldn't it be better to report upstream and provide the patch instead
of just patching within the build?


Definitely.

In a linux distribution or a project such as ours with so many external 
dependencies there are good reasons not to always use the latest version 
of each component: That could easily result in endless churn and prevent 
releases. So backporting fixes is an alternative that should is often 
preferable. I don't know the background of the issues mentioned above 
that were fixed for HSQLDB but maybe they were such backports of fixes?



There are also checks within the code
to specifically check for version 1.8.x, not sure  wouldn't it be better
to enforce on configure/bootstrap? The current way seem to require a lot
more work to update dependencies and the with-system-hsqldb for
configure provides no warning.


Using configure for checking this and cleaning up checks for obsoleted 
versions is a good plan. Please go ahead.



I will take a look at the open issues and see if it is resolved with the
new version.

I am guessing my next steps would be looking into updating the build to
pull the jar?


Better use the mechanism provided by main/external_deps.lst

Herbert

Re: Updating Java libraries

[Michael Lam]

On 02/06/2013 12:50 PM, Kay Schenk wrote:



On 02/06/2013 06:15 AM, Michael Lam wrote:

On 02/06/2013 05:57 AM, Herbert Duerr wrote:

I just saw that Ariel had already provided an excellent answer when I
had trouble with my mail connection. Sorry about that.

On 06.02.2013 11:49, Herbert Duerr wrote:

Hi Michael,

On 06.02.2013 04:06, Michael Lam wrote:

I would like to update some of the Java libraries used, starting with
hsqldb. Is there any preference to getting the source and building 
the

jar or just grabbing the jar from the project site?


Some other Apache projects are redistributing unmodified upstream 
JARs,

so I guess we could do this as well and this would simplify the build.


There are four BZ
issues in reference to hsqldb with patches, I am going to test the 
new

version to make sure those issues are resolved but they are very old.
Should I open another issue for this?


Opening just one issue with task about updating hsqldb should suffice.


Is there any recommendation/objection on this? After hsqldb I would
like
to move on to lucene.


Thank you very much for working on this!


Just a general question, there are many old issues on BZ for example
there are 96 for hsqldb but most of them are from 2006 and is 
referring
to an old version of OpenOffice, would it be possible to close 
very old

issues?


Sure, obsolete issues can be closed. Quickly skimping over the list of
hsqldb issues [1] shows that some problems may be generic and could
still be relevant. Having their reports and descriptions on how to
reproduce them could be valuable enough to reconsider closing them.
Maybe they are interesting test cases when you upgraded hsqldb?

[1] http://s.apache.org/aoo_hsqldb_open

Herbert




Thank you Herbert and Ariel. I already have a build with the latest code
from SVN and the latest jar from hsqldb. I was thinking the same as
using the existing issues especially the one with the patches as test
cases to make sure the new jar doesn't introduce regression.


Good going Michael!! Ok, you used latest HSQLDB jar, hsqldb-2.2.9, and 
which version of java on your system?


And yes, looking through old dba dev mail archives did prove 
useful/interesting, as well as information starting in:


http://www.openoffice.org/dba/



I can look into updating the files both ways to build but I would think
it is better to just retrieve the jar and simplify the build process. As
a new volunteer, the current process is quite complex even with the
great documentation. I think simplifying it by concentrating on the core
openoffice code would be helpful.




I have successfully test hsqldb-2.2.9 against the following 4 issues and 
it is functioning correctly:

https://issues.apache.org/ooo/show_bug.cgi?id=96823
https://issues.apache.org/ooo/show_bug.cgi?id=103528
https://issues.apache.org/ooo/show_bug.cgi?id=104901
https://issues.apache.org/ooo/show_bug.cgi?id=97032

and I have looked at

http://hg.services.openoffice.org/cws/hsqldb19/

Unless I am looking at this wrong, many of the changes are not related to 
hsqldb19 and it is already in the latest revision. As for the hsqldb specific, 
the patches does not apply to 2.2.9. As far as patches, wouldn't it be better 
to report upstream and provide the patch instead of just patching within the 
build? There are also checks within the code to specifically check for version 
1.8.x, not sure  wouldn't it be better to enforce on configure/bootstrap? The 
current way seem to require a lot more work to update dependencies and the 
with-system-hsqldb for configure provides no warning.

I will take a look at the open issues and see if it is resolved with the new 
version.

I am guessing my next steps would be looking into updating the build to pull 
the jar?

Michael

Re: Updating Java libraries

[Michael Lam]

On 02/06/2013 03:58 PM, Dave Fisher wrote:

On Feb 5, 2013, at 8:26 PM, Ariel Constenla-Haile wrote:


Is there any recommendation/objection on this? After hsqldb I would
like to move on to lucene.

In this case, it would be nice to investigate if lucence can be replaced
by clucene, this will reduce the need of installing Java for basic
stuff, like the Online Help.


Apache Lucy is a C version of Apache Lucene

http://lucy.apache.org/

Regards,
Dave

That is certainly an option, although it comes down to how it is used, 
if it is only for searching the help, it might not need all the new 
functionality in the latest Lucene. Since Lucy is a loose port of 
Lucene, I am not sure if the updates on Lucene are ported although some 
are Java centric and the same issue might not be applicable in C.


Michael

Re: Updating Java libraries

[Dave Fisher]

On Feb 5, 2013, at 8:26 PM, Ariel Constenla-Haile wrote:

>> Is there any recommendation/objection on this? After hsqldb I would
>> like to move on to lucene.
> 
> In this case, it would be nice to investigate if lucence can be replaced
> by clucene, this will reduce the need of installing Java for basic
> stuff, like the Online Help.
> 

Apache Lucy is a C version of Apache Lucene

http://lucy.apache.org/

Regards,
Dave

Re: Updating Java libraries

[Michael Lam]

On 02/06/2013 12:50 PM, Kay Schenk wrote:



On 02/06/2013 06:15 AM, Michael Lam wrote:

On 02/06/2013 05:57 AM, Herbert Duerr wrote:

I just saw that Ariel had already provided an excellent answer when I
had trouble with my mail connection. Sorry about that.

On 06.02.2013 11:49, Herbert Duerr wrote:

Hi Michael,

On 06.02.2013 04:06, Michael Lam wrote:

I would like to update some of the Java libraries used, starting with
hsqldb. Is there any preference to getting the source and building 
the

jar or just grabbing the jar from the project site?


Some other Apache projects are redistributing unmodified upstream 
JARs,

so I guess we could do this as well and this would simplify the build.


There are four BZ
issues in reference to hsqldb with patches, I am going to test the 
new

version to make sure those issues are resolved but they are very old.
Should I open another issue for this?


Opening just one issue with task about updating hsqldb should suffice.


Is there any recommendation/objection on this? After hsqldb I would
like
to move on to lucene.


Thank you very much for working on this!


Just a general question, there are many old issues on BZ for example
there are 96 for hsqldb but most of them are from 2006 and is 
referring
to an old version of OpenOffice, would it be possible to close 
very old

issues?


Sure, obsolete issues can be closed. Quickly skimping over the list of
hsqldb issues [1] shows that some problems may be generic and could
still be relevant. Having their reports and descriptions on how to
reproduce them could be valuable enough to reconsider closing them.
Maybe they are interesting test cases when you upgraded hsqldb?

[1] http://s.apache.org/aoo_hsqldb_open

Herbert




Thank you Herbert and Ariel. I already have a build with the latest code
from SVN and the latest jar from hsqldb. I was thinking the same as
using the existing issues especially the one with the patches as test
cases to make sure the new jar doesn't introduce regression.


Good going Michael!! Ok, you used latest HSQLDB jar, hsqldb-2.2.9, and 
which version of java on your system?


And yes, looking through old dba dev mail archives did prove 
useful/interesting, as well as information starting in:


http://www.openoffice.org/dba/



I can look into updating the files both ways to build but I would think
it is better to just retrieve the jar and simplify the build process. As
a new volunteer, the current process is quite complex even with the
great documentation. I think simplifying it by concentrating on the core
openoffice code would be helpful.




I currently have jdk1.6.0_35. I also have jdk1.7.0_07. Once I do a quick 
pass with the existing build with jdk6. I will give it a try with jdk7 also.


Thank you all for the links. I am getting a better picture of the 
project already.

Re: Updating Java libraries

[Kay Schenk]

On 02/06/2013 06:15 AM, Michael Lam wrote:

On 02/06/2013 05:57 AM, Herbert Duerr wrote:

I just saw that Ariel had already provided an excellent answer when I
had trouble with my mail connection. Sorry about that.

On 06.02.2013 11:49, Herbert Duerr wrote:

Hi Michael,

On 06.02.2013 04:06, Michael Lam wrote:

I would like to update some of the Java libraries used, starting with
hsqldb. Is there any preference to getting the source and building the
jar or just grabbing the jar from the project site?


Some other Apache projects are redistributing unmodified upstream JARs,
so I guess we could do this as well and this would simplify the build.


There are four BZ
issues in reference to hsqldb with patches, I am going to test the new
version to make sure those issues are resolved but they are very old.
Should I open another issue for this?


Opening just one issue with task about updating hsqldb should suffice.


Is there any recommendation/objection on this? After hsqldb I would
like
to move on to lucene.


Thank you very much for working on this!


Just a general question, there are many old issues on BZ for example
there are 96 for hsqldb but most of them are from 2006 and is referring
to an old version of OpenOffice, would it be possible to close very old
issues?


Sure, obsolete issues can be closed. Quickly skimping over the list of
hsqldb issues [1] shows that some problems may be generic and could
still be relevant. Having their reports and descriptions on how to
reproduce them could be valuable enough to reconsider closing them.
Maybe they are interesting test cases when you upgraded hsqldb?

[1] http://s.apache.org/aoo_hsqldb_open

Herbert




Thank you Herbert and Ariel. I already have a build with the latest code
from SVN and the latest jar from hsqldb. I was thinking the same as
using the existing issues especially the one with the patches as test
cases to make sure the new jar doesn't introduce regression.


Good going Michael!! Ok, you used latest HSQLDB jar, hsqldb-2.2.9, and 
which version of java on your system?


And yes, looking through old dba dev mail archives did prove 
useful/interesting, as well as information starting in:


http://www.openoffice.org/dba/



I can look into updating the files both ways to build but I would think
it is better to just retrieve the jar and simplify the build process. As
a new volunteer, the current process is quite complex even with the
great documentation. I think simplifying it by concentrating on the core
openoffice code would be helpful.




--

MzK

"A great deal of talent is lost to the world
  for want of a little courage."
 -- Sydney Smith

Re: Updating Java libraries

[Pedro Giffuni]

Hello Michael;

Updating those libraries is a bit of a task.

For the hsqldb update you would need to start looking at the code here:

http://hg.services.openoffice.org/cws/hsqldb19/


For Lucene (which I updated) you need to fix the long_path patch
so that it applies to the new Lucene version.

Updating stuff is good way to learn about OpenOffice (I started
that way). If you want an easy task, update libxslt.

Pedro.

Re: Updating Java libraries

[Michael Lam]

On 02/06/2013 05:57 AM, Herbert Duerr wrote:
I just saw that Ariel had already provided an excellent answer when I 
had trouble with my mail connection. Sorry about that.


On 06.02.2013 11:49, Herbert Duerr wrote:

Hi Michael,

On 06.02.2013 04:06, Michael Lam wrote:

I would like to update some of the Java libraries used, starting with
hsqldb. Is there any preference to getting the source and building the
jar or just grabbing the jar from the project site?


Some other Apache projects are redistributing unmodified upstream JARs,
so I guess we could do this as well and this would simplify the build.


There are four BZ
issues in reference to hsqldb with patches, I am going to test the new
version to make sure those issues are resolved but they are very old.
Should I open another issue for this?


Opening just one issue with task about updating hsqldb should suffice.

Is there any recommendation/objection on this? After hsqldb I would 
like

to move on to lucene.


Thank you very much for working on this!


Just a general question, there are many old issues on BZ for example
there are 96 for hsqldb but most of them are from 2006 and is referring
to an old version of OpenOffice, would it be possible to close very old
issues?


Sure, obsolete issues can be closed. Quickly skimping over the list of
hsqldb issues [1] shows that some problems may be generic and could
still be relevant. Having their reports and descriptions on how to
reproduce them could be valuable enough to reconsider closing them.
Maybe they are interesting test cases when you upgraded hsqldb?

[1] http://s.apache.org/aoo_hsqldb_open

Herbert



Thank you Herbert and Ariel. I already have a build with the latest code 
from SVN and the latest jar from hsqldb. I was thinking the same as 
using the existing issues especially the one with the patches as test 
cases to make sure the new jar doesn't introduce regression.


I can look into updating the files both ways to build but I would think 
it is better to just retrieve the jar and simplify the build process. As 
a new volunteer, the current process is quite complex even with the 
great documentation. I think simplifying it by concentrating on the core 
openoffice code would be helpful.

Re: Updating Java libraries

[Herbert Duerr]

I just saw that Ariel had already provided an excellent answer when I 
had trouble with my mail connection. Sorry about that.


On 06.02.2013 11:49, Herbert Duerr wrote:

Hi Michael,

On 06.02.2013 04:06, Michael Lam wrote:

I would like to update some of the Java libraries used, starting with
hsqldb. Is there any preference to getting the source and building the
jar or just grabbing the jar from the project site?


Some other Apache projects are redistributing unmodified upstream JARs,
so I guess we could do this as well and this would simplify the build.


There are four BZ
issues in reference to hsqldb with patches, I am going to test the new
version to make sure those issues are resolved but they are very old.
Should I open another issue for this?


Opening just one issue with task about updating hsqldb should suffice.


Is there any recommendation/objection on this? After hsqldb I would like
to move on to lucene.


Thank you very much for working on this!


Just a general question, there are many old issues on BZ for example
there are 96 for hsqldb but most of them are from 2006 and is referring
to an old version of OpenOffice, would it be possible to close very old
issues?


Sure, obsolete issues can be closed. Quickly skimping over the list of
hsqldb issues [1] shows that some problems may be generic and could
still be relevant. Having their reports and descriptions on how to
reproduce them could be valuable enough to reconsider closing them.
Maybe they are interesting test cases when you upgraded hsqldb?

[1] http://s.apache.org/aoo_hsqldb_open

Herbert

Re: Updating Java libraries

[Herbert Duerr]

Hi Michael,

On 06.02.2013 04:06, Michael Lam wrote:

I would like to update some of the Java libraries used, starting with
hsqldb. Is there any preference to getting the source and building the
jar or just grabbing the jar from the project site?


Some other Apache projects are redistributing unmodified upstream JARs, 
so I guess we could do this as well and this would simplify the build.



There are four BZ
issues in reference to hsqldb with patches, I am going to test the new
version to make sure those issues are resolved but they are very old.
Should I open another issue for this?


Opening just one issue with task about updating hsqldb should suffice.


Is there any recommendation/objection on this? After hsqldb I would like
to move on to lucene.


Thank you very much for working on this!


Just a general question, there are many old issues on BZ for example
there are 96 for hsqldb but most of them are from 2006 and is referring
to an old version of OpenOffice, would it be possible to close very old
issues?


Sure, obsolete issues can be closed. Quickly skimping over the list of 
hsqldb issues [1] shows that some problems may be generic and could 
still be relevant. Having their reports and descriptions on how to 
reproduce them could be valuable enough to reconsider closing them. 
Maybe they are interesting test cases when you upgraded hsqldb?


[1] http://s.apache.org/aoo_hsqldb_open

Herbert

Re: Updating Java libraries

[Ariel Constenla-Haile]

Hi Michael,

On Tue, Feb 05, 2013 at 10:06:35PM -0500, Michael Lam wrote:
> I would like to update some of the Java libraries used, starting
> with hsqldb. 

It seems like updating this will require a deep insight in OpenOffice
Base code, there was work going on in a dedicate Mercurial CWS to update
to HSQLDB 1.9
http://hg.services.openoffice.org/cws/hsqldb19/

Unfortunately the developer (Ocke Janssen) is no longer working in
OpenOffice.

> Is there any preference to getting the source and building the jar or
> just grabbing the jar from the project site?  

You should support, via configure, building the JAR from sources and use
the --with-system-XXX switch in order to use an already compiled version
existing in the target system (this applies to Linux, not WIN; for WIN
AOO ships all stuff).

Simply run ./configure --help and read a little configure.in, you'll see
this approach used for other JARs with a compatible license.

> There are four BZ issues in reference to hsqldb with patches, I am
> going to test the new version to make sure those issues are resolved
> but they are very old.  Should I open another issue for this?

If you are planning to update to 2.2, then this is a new task.

> Is there any recommendation/objection on this? After hsqldb I would
> like to move on to lucene.

In this case, it would be nice to investigate if lucence can be replaced
by clucene, this will reduce the need of installing Java for basic
stuff, like the Online Help.


> Just a general question, there are many old issues on BZ for example
> there are 96 for hsqldb but most of them are from 2006 and is
> referring to an old version of OpenOffice, would it be possible to
> close very old issues?

Depending how you close the issue: closing an issue as FIXED requires
verification, closing it as WONTFIX requires simply an argument why it
won't be fixed. In the case of hsqldb, IMHO issues should be checked if
they are still reproducible, and once the newer version is integrated,
it should be checked if updating simply solved them or are still open.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpom4NKc9Ijv.pgp
Description: PGP signature

Re: Updating Java libraries

[Fernando Cassia]

On Wed, Feb 6, 2013 at 12:06 AM, Michael Lam  wrote:
> Is there any recommendation/objection on this? After hsqldb I would like to
> move on to lucene.

sounds good. :)
For me, go ahead.  I don´t know any other repository than the
project´s sourceforge page, where it lists

hsqldb-2.2.9.zip2012-08-06  7.5 MB

...as the latest version.

But then I´m only a lurker on this list.
FC

Updating Java libraries

[Michael Lam]

I would like to update some of the Java libraries used, starting with 
hsqldb. Is there any preference to getting the source and building the 
jar or just grabbing the jar from the project site? There are four BZ 
issues in reference to hsqldb with patches, I am going to test the new 
version to make sure those issues are resolved but they are very old. 
Should I open another issue for this?


Is there any recommendation/objection on this? After hsqldb I would like 
to move on to lucene.


Just a general question, there are many old issues on BZ for example 
there are 96 for hsqldb but most of them are from 2006 and is referring 
to an old version of OpenOffice, would it be possible to close very old 
issues?


Michael