Re: Updating Java libraries
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 arie...@apache.org 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
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 arie...@apache.org 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
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
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
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
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
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
On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr h...@apache.org 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=96823https://issues.apache.org/ooo/show_bug.cgi?id=96823 https://issues.apache.org/ooo/**show_bug.cgi?id=103528https://issues.apache.org/ooo/show_bug.cgi?id=103528 https://issues.apache.org/ooo/**show_bug.cgi?id=104901https://issues.apache.org/ooo/show_bug.cgi?id=104901 https://issues.apache.org/ooo/**show_bug.cgi?id=97032https://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/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
On 02/11/2013 01:16 PM, Kay Schenk wrote: On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr h...@apache.org 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=96823https://issues.apache.org/ooo/show_bug.cgi?id=96823 https://issues.apache.org/ooo/**show_bug.cgi?id=103528https://issues.apache.org/ooo/show_bug.cgi?id=103528 https://issues.apache.org/ooo/**show_bug.cgi?id=104901https://issues.apache.org/ooo/show_bug.cgi?id=104901 https://issues.apache.org/ooo/**show_bug.cgi?id=97032https://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/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
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 mnsyl4...@verizon.net wrote: On 02/11/2013 01:16 PM, Kay Schenk wrote: On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr h...@apache.org 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=96823https://issues.apache.org/ooo/show_bug.cgi?id=96823 https://issues.apache.org/ooo/**show_bug.cgi?id=103528https://issues.apache.org/ooo/show_bug.cgi?id=103528 https://issues.apache.org/ooo/**show_bug.cgi?id=104901https://issues.apache.org/ooo/show_bug.cgi?id=104901 https://issues.apache.org/ooo/**show_bug.cgi?id=97032https://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/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
On Mon, Feb 11, 2013 at 2:06 PM, Michael Lam mnsyl4...@verizon.net 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
On Mon, Feb 11, 2013 at 2:16 PM, Fred Ollinger folli...@gmail.com 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
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 fcas...@gmail.com wrote: On Mon, Feb 11, 2013 at 2:16 PM, Fred Ollinger folli...@gmail.com 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
On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger folli...@gmail.com 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
OK, I won't build with java6 anymore then. Fred On Mon, Feb 11, 2013 at 12:30 PM, Fernando Cassia fcas...@gmail.com wrote: On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger folli...@gmail.com 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
On Mon, Feb 11, 2013 at 5:19 PM, Fred Ollinger folli...@gmail.com 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
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 fcas...@gmail.com wrote: On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger folli...@gmail.com 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
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 fcas...@gmail.com wrote: On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger folli...@gmail.com 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
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
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
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
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
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
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
