Upgrading Lucene jars to 2.9.2 artifacts
Any objections? -- Regards, Shalin Shekhar Mangar.
Re: Upgrading Lucene jars to 2.9.2 artifacts
On 02/27/2010 05:53 AM, Shalin Shekhar Mangar wrote: Any objections? Didn't rc2 (that we are on) end up being the final release? -- - Mark http://www.lucidimagination.com
Re: Upgrading Lucene jars to 2.9.2 artifacts
On Sat, Feb 27, 2010 at 8:04 PM, Mark Miller markrmil...@gmail.com wrote: On 02/27/2010 05:53 AM, Shalin Shekhar Mangar wrote: Any objections? Didn't rc2 (that we are on) end up being the final release? Hmm, I didn't know that. But the lucene contrib jars checked in trunk are different from the ones on Maven. The revision number is same but the date/time of the build is different. For example, the lucene-analyzers-2.9.2.jar: Maven - Implementation-Version: 2.9.2 912433 - 2010-02-22 00:00:06 Trunk - Implementation-Version: 2.9.2 912433 - 2010-02-21 23:52:03 -- Regards, Shalin Shekhar Mangar.
Re: Upgrading Lucene jars to 2.9.2 artifacts
On Sat, Feb 27, 2010 at 9:34 AM, Mark Miller markrmil...@gmail.com wrote: On 02/27/2010 05:53 AM, Shalin Shekhar Mangar wrote: Any objections? Didn't rc2 (that we are on) end up being the final release? Yep - I just updated CHANGES.txt -Yonik http://www.lucidimagination.com
Re: Upgrading Lucene jars to 2.9.2 artifacts
On Sat, Feb 27, 2010 at 9:49 AM, Shalin Shekhar Mangar shalinman...@gmail.com wrote: But the lucene contrib jars checked in trunk are different from the ones on Maven. The revision number is same but the date/time of the build is different. For example, the lucene-analyzers-2.9.2.jar: Maven - Implementation-Version: 2.9.2 912433 - 2010-02-22 00:00:06 Trunk - Implementation-Version: 2.9.2 912433 - 2010-02-21 23:52:03 *shrug* - don't know how the maven stuff gets done, but I just re-downloaded the official 2.9.2 (the .tar.gz version) and verified that the checksums match what we have in solr's lib. -Yonik http://www.lucidimagination.com
Upgrading Lucene jars
I'd like to upgrade all Lucene jars to the latest 2.9 branch (r900222). If there is no objections, I'll commit tomorrow. Now I'm testing Lucene 2.9 branch and Solr trunk with latest 2.9. Thank you, Koji -- http://www.rondhuit.com/en/
Re: Upgrading Lucene jars
I'm not using Embedded Solr directly, I've seen several projects depending on Lucene as a Maven artifact and include also a dependency on some solr module as a general utility, for example to use some solr analysers. Let's say you had Lucene 2.4.1, when adding solr-analysers version 1.3.0 in the mix it appears to work well in testing, until the classloading order changes in an application server and you'll find out that maven will have added the solr-lucene-core artifact too, which looks like fine unless you know what's in there. The poor developer could have a hard time to find out that he is having two artifacts with different identifiers and different jar names containing same code at different versions, after noticing some undefined field or method. I've learnt the lesson so I don't speak to help myself, but I think it would be an improvement and make life easier for others; Maven should take care of this but it's actually giving a false feeling of confidence in this case. Regards, Sanne 2009/12/9 Shalin Shekhar Mangar shalinman...@gmail.com: On Wed, Dec 9, 2009 at 3:33 PM, Sanne Grinovero sanne.grinov...@gmail.comwrote: Why is Solr not depending directly on Lucene but repackaging the same classes? Solr does depend on Lucene jars. We strive to package officially released Lucene artifacts but sometimes the release schedule of Lucene and Solr are different enough to build and package Lucene jars ourselves. The CHANGES.txt in the Solr distribution has the version of Lucene used in that distribution. For example, Solr 1.4 released with Lucene 2.9.1 Solr 1.4 has already released and we are free to upgrade Lucene jars in trunk to any version we desire for further development. Sorry I've probably missed some important discussion. Whatever the reason for this decision, is it still a good reason? This gets new users in a hell of trouble sometimes, as some applications introduce Solr after having Lucene already on the classpath and it's not immediately obvious that differently named jars contain same named classes. Are you using Embedded Solr? Otherwise the Lucene jars are in the solr.war's WEB-INF/lib directory and there is no chance of a conflict. -- Regards, Shalin Shekhar Mangar.
Re: Upgrading Lucene jars
Why is Solr not depending directly on Lucene but repackaging the same classes? Sorry I've probably missed some important discussion. Whatever the reason for this decision, is it still a good reason? This gets new users in a hell of trouble sometimes, as some applications introduce Solr after having Lucene already on the classpath and it's not immediately obvious that differently named jars contain same named classes. Could this be a good timeframe to change this? Regards, Sanne 2009/12/8 Koji Sekiguchi k...@r.email.ne.jp: Shalin Shekhar Mangar wrote: I need to upgrade contrib-spellcheck jar for SOLR-785. Should I go ahead and upgrade all Lucene jars to the latest 2.9 branch code? +1. Koji -- http://www.rondhuit.com/en/
Re: Upgrading Lucene jars
On Wed, Dec 9, 2009 at 3:33 PM, Sanne Grinovero sanne.grinov...@gmail.comwrote: Why is Solr not depending directly on Lucene but repackaging the same classes? Solr does depend on Lucene jars. We strive to package officially released Lucene artifacts but sometimes the release schedule of Lucene and Solr are different enough to build and package Lucene jars ourselves. The CHANGES.txt in the Solr distribution has the version of Lucene used in that distribution. For example, Solr 1.4 released with Lucene 2.9.1 Solr 1.4 has already released and we are free to upgrade Lucene jars in trunk to any version we desire for further development. Sorry I've probably missed some important discussion. Whatever the reason for this decision, is it still a good reason? This gets new users in a hell of trouble sometimes, as some applications introduce Solr after having Lucene already on the classpath and it's not immediately obvious that differently named jars contain same named classes. Are you using Embedded Solr? Otherwise the Lucene jars are in the solr.war's WEB-INF/lib directory and there is no chance of a conflict. -- Regards, Shalin Shekhar Mangar.
Upgrading Lucene jars
I need to upgrade contrib-spellcheck jar for SOLR-785. Should I go ahead and upgrade all Lucene jars to the latest 2.9 branch code? -- Regards, Shalin Shekhar Mangar.
Re: Upgrading Lucene jars
Shalin Shekhar Mangar wrote: I need to upgrade contrib-spellcheck jar for SOLR-785. Should I go ahead and upgrade all Lucene jars to the latest 2.9 branch code? +1. Koji -- http://www.rondhuit.com/en/
Upgrading lucene jars again
Any objections to upgrading Lucene jars again? Following are the changes since the last upgrade: LUCENE-1634: add calibrateSizeByDeletes to LogMergePolicy LUCENE-1629: correct ASF source headers LUCENE-1638: fix thread hazard when autoCommit=true and multiple threads are committing LUCENE-1596: check that enum and termdocs came from same reader before invoking optimization LUCENE-1596: MultiTermDocs speedup when set with MultiTermDocs.seek(MultiTermEnum) LUCENE-1629: set javadocs encoding to UTF-8 LUCENE-1629: move CHANGES entry to contrib; add TestArabicAnalyzer LUCENE-1629: adding new contrib analyzer SmartChineseAnalyzer pendingOutput is a bit generic for a field in a large class - changed to pendingSegnOutput -- Regards, Shalin Shekhar Mangar.
Re: Upgrading lucene jars again
Shalin Shekhar Mangar wrote: Any objections to upgrading Lucene jars again? None here. +1. -- - Mark http://www.lucidimagination.com
