Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
One of the benefits of moving forward with the conversion of the Java Lucene, is that they're using more recent versions of Java that support things like generics and enums, so the direct port is getting more and more like .NET, though not in all respects of course. I'm of the mind, though, that one of the larger annoyances, Iterables, should be converted to Enumerables in the direct port. It makes it a pain to use it in .NET without it inheriting from IEnumerable, since it can't be used in a foreach loop or with linq. Also, since the direct port isn't perfect anyway, it seems a port of the IDEA of iterating would be more in the spirit of what we're trying to accomplish, since the code would pretty much be the same, just with different method names. I sort of got off topic there for a second, but I guess the future of 2.9.4g depends on the extent that it is becoming more .NET like. Obviously, while java is starting to use similar constructs that we have in .NET, it will never be perfect. Admittedly, I haven't looked at 2.9.4g in a little while, so I'm not sure how much it now differs from 3.x, since there's a relatively large change there already. Thanks, Christopher On Thu, Dec 22, 2011 at 9:13 PM, Prescott Nasser geobmx...@hotmail.comwrote: That's a great question - I know a lot of people like the generics, and I don't really want it to disappear. I'd like to keep it in parity with the trunk. But I know we also have a goal of making Lucene.Net more .Net like (further than 2.9.4g), and I don't know how that fits in. We are a pretty small community and I know everyone has some pretty busy schedules so it takes us considerable time to make big progress. Trying to keep three different code bases probably isn't the right way to go. Date: Fri, 23 Dec 2011 13:02:03 +1100 From: mitiag...@gmail.com To: lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g I was browsing Roadmap emails from November in Lucene developer list. It remains unclear in what state Lucene 3 porting is , but my question more about 2.9.4g . Is it kind of experimental dead end variation of 2.9.4 with generics ? Am I right in classifying it as more .Net like 2.9.4 which is unrelated to roadmap Lucene 3 porting effort.
Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
I'm not that proficient in JIRA yet, and can only find 22 open issues outstanding. Is this correct, or am I missing something? -r On Fri, Dec 23, 2011 at 2:38 PM, Prescott Nasser geobmx...@hotmail.comwrote: You can look at the jira issues for Java lucene 3.0.3 and submit patches for 2.9.4g that will bring it up. Worst case is well keep trying to maintain a line by line and the g. Best case is we can use g as a jump point to make it even more .net like and whatever work you do will help us there as well Sent from my Windows Phone From: Rory Plaire Sent: 12/23/2011 2:27 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress So, if there was a very-occasional contributor who wanted to put some time into the project this weekend, is there a way to do it at this time? I'm only interested in the generics port as well as making sure that the translation offers (at least one-way) compatibility with Lucene indexes. -r On Fri, Dec 23, 2011 at 1:32 PM, Prescott Nasser geobmx...@hotmail.com wrote: I don't know if we should do that - the generics is quite different from the line by line port. I would vote we do it personally - I know others are not ok with it. What say other people? Sent from my Windows Phone From: Scott Lombard Sent: 12/23/2011 11:21 AM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress The Anonymous class issue is a readability issue not a functional change. So the release could go forward without it. The work should be continued in the 3.0.3 version. Prescott are you planning on merging the 2.9.4g into the trunk then 3.0.3? Scott -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Thursday, December 22, 2011 4:37 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress Im not as familiar with the g branch - the notice issue is current, seems like the general incubator has been digging everyone for it lately. Im not sure about the anon or the generics unfortunately Sent from my Windows Phone From: Rory Plaire Sent: 12/22/2011 12:58 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress I was just looking at the issues for 2.9.4g since I have a bit of time to put against them in the coming week. They are here: https://issues.apache.org/jira/browse/LUCENENET/fixforversion/ 12316479. Are these current? If so I can just keep going in the direction DIGY set to help close them. -r On Thu, Dec 22, 2011 at 10:12 AM, michael herndon mhern...@wickedsoftware.net wrote: +1 I believe you tagged the latest during release. Code be reverted +or a new branch to create a patch for 2.9.4 if something major happens since we have scm in place, so I think merging it would not be damaging in any way. for the 2.9.4g branch, I would do a quick scan to see if there are any outstanding tickets or input from DIGY or anyone else who put in major time on that branch. If there are things that are outstanding, throw together a quick list that people can pull from and work through. I can throw up some tweets and point towards this thread if you would like. - Michael On Thu, Dec 22, 2011 at 12:55 PM, Prescott Nasser geobmx...@hotmail.com wrote: Its been pretty quiet as of late. I'd like to merge 3.0.3 into the trunk and wipe out the branch. Im going to do this by lazy consensus since responses are a little difficult to come by. Im going to do this Jan 5th - after the holidays to give everyone the opportunity to respond if they think this is a bad idea. I will do it quicker if people respond it is a good idea however. I am also going to package up 2.9.4g the week between the two holidays - if there is anything that needs to get done lets get it taken care of. Finally, if I dont hear any other way in the next day or two I am going to copy the Java lucene jira issues for 3.0.3 release into our jira so that we can track and start knocking them down. Happy holidays all, Prescott Sent from my Windows Phone
RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
but I guess the future of 2.9.4g depends on the extent that it is becoming more .NET like My intention while I was creating that branch was just to make 2.9.4 a little bit more .Net like(+ maybe some performance). I used many codes from 3.0.3 Java. So it is somewhere between 2.9.4 3.0.3 But I didn't think it as a separate branch to evolve on its own path. It is(or I think it is) the final version of 2.9 DIGY -Original Message- From: Christopher Currens [mailto:currens.ch...@gmail.com] Sent: Wednesday, December 28, 2011 9:20 PM To: lucene-net-dev@lucene.apache.org Cc: lucene-net-u...@lucene.apache.org Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g One of the benefits of moving forward with the conversion of the Java Lucene, is that they're using more recent versions of Java that support things like generics and enums, so the direct port is getting more and more like .NET, though not in all respects of course. I'm of the mind, though, that one of the larger annoyances, Iterables, should be converted to Enumerables in the direct port. It makes it a pain to use it in .NET without it inheriting from IEnumerable, since it can't be used in a foreach loop or with linq. Also, since the direct port isn't perfect anyway, it seems a port of the IDEA of iterating would be more in the spirit of what we're trying to accomplish, since the code would pretty much be the same, just with different method names. I sort of got off topic there for a second, but I guess the future of 2.9.4g depends on the extent that it is becoming more .NET like. Obviously, while java is starting to use similar constructs that we have in .NET, it will never be perfect. Admittedly, I haven't looked at 2.9.4g in a little while, so I'm not sure how much it now differs from 3.x, since there's a relatively large change there already. Thanks, Christopher On Thu, Dec 22, 2011 at 9:13 PM, Prescott Nasser geobmx...@hotmail.comwrote: That's a great question - I know a lot of people like the generics, and I don't really want it to disappear. I'd like to keep it in parity with the trunk. But I know we also have a goal of making Lucene.Net more .Net like (further than 2.9.4g), and I don't know how that fits in. We are a pretty small community and I know everyone has some pretty busy schedules so it takes us considerable time to make big progress. Trying to keep three different code bases probably isn't the right way to go. Date: Fri, 23 Dec 2011 13:02:03 +1100 From: mitiag...@gmail.com To: lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g I was browsing Roadmap emails from November in Lucene developer list. It remains unclear in what state Lucene 3 porting is , but my question more about 2.9.4g . Is it kind of experimental dead end variation of 2.9.4 with generics ? Am I right in classifying it as more .Net like 2.9.4 which is unrelated to roadmap Lucene 3 porting effort. - Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4708 - Release Date: 12/28/11
RE: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
That's 40 issues that the Java Lucene team tagged as needed for 3.0.3 release (so they are all closed atm) I will try to port many/most of these over this week into our JIRA so we can track them for ourselves. From: geobmx...@hotmail.com To: lucene-net-dev@lucene.apache.org Date: Wed, 28 Dec 2011 17:21:39 -0800 Subject: RE: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress 40 issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+LUCENE+AND+fixVersion+%3D+%223.0.3%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide Date: Wed, 28 Dec 2011 15:18:22 -0800 From: codekai...@gmail.com To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress I'm not that proficient in JIRA yet, and can only find 22 open issues outstanding. Is this correct, or am I missing something? -r On Fri, Dec 23, 2011 at 2:38 PM, Prescott Nasser wrote: You can look at the jira issues for Java lucene 3.0.3 and submit patchesfor 2.9.4g that will bring it up. Worst case is well keep trying tomaintain a line by line and the g. Best case is we can use g as a jumppoint to make it even more .net like and whatever work you do will help usthere as well Sent from my Windows PhoneFrom: Rory PlaireSent: 12/23/2011 2:27 PMTo: lucene-net-dev@lucene.apache.orgSubject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress So, if there was a very-occasional contributor who wanted to put some timeinto the project this weekend, is there a way to do it at this time?I'm only interested in the generics port as well as making sure that thetranslation offers (at least one-way) compatibility with Lucene indexes.-r On Fri, Dec 23, 2011 at 1:32 PM, Prescott Nasser wrote:I don't know if we should do that - the generics is quite different from the line by line port. I would vote we do it personally - I know othersare not ok with it. What say other people? Sent from my Windows Phone From: Scott Lombard Sent: 12/23/2011 11:21 AM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Merge 3.0.3 into trunk and other forwardprogress The Anonymous class issue is a readability issue not a functional change. So the release could go forward without it. The work should be continued in the 3.0.3 version. Prescott are you planning on merging the 2.9.4g into the trunk then3.0.3? Scott -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Thursday, December 22, 2011 4:37 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress Im not as familiar with the g branch - the notice issue is current, seems like the general incubator has been digging everyone for it lately. Im not sure about the anon or the generics unfortunately Sent from my Windows Phone From: Rory Plaire Sent: 12/22/2011 12:58 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress I was just looking at the issues for 2.9.4g since I have a bit of time to put against them in the coming week. They are here: https://issues.apache.org/jira/browse/LUCENENET/fixforversion/ 12316479. Are these current? If so I can just keep going in the direction DIGY set to help close them. -r On Thu, Dec 22, 2011 at 10:12 AM, michael herndon mhern...@wickedsoftware.net wrote:+1 I believe you tagged the latest during release. Code be reverted +or a new branch to create a patch for 2.9.4 if something major happens since we have scm in place, so I think merging it would not be damaging in any way. for the 2.9.4g branch, I would do a quick scan to see if there are any outstanding tickets or input from DIGY or anyone else who put in major time on that branch. If there are things that are outstanding, throw together a quick list that people can pull from and work through. I can throw up some tweets and point towards this thread if you would like. - Michael On Thu, Dec 22, 2011 at 12:55 PM, Prescott Nasserwrote: Its been pretty quiet as of late. I'd like to merge 3.0.3 into the trunk and wipe out the branch. Im going to do this by lazy consensus since responses are a little
RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
Any reason we can't continue this g branch and make it more and more .net like? I was thinking about what we've expressed at goals - we want a line by line port - it's easy to maintain parity with java and easy to compare. We also want a more .NET version - the g branch gets this started - although it's not as .Net as people want (I think). What if we used the g branch as our .Net version and continued to make it more .Net like? and kept the trunk as the line by line? The G branch seems like a good start to the more .Net version anyway - we might as well build off of that? From: digyd...@gmail.com To: lucene-net-dev@lucene.apache.org Date: Thu, 29 Dec 2011 02:45:23 +0200 Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4gbut I guess the future of 2.9.4g depends on the extent that it is becoming more .NET like My intention while I was creating that branch was just to make 2.9.4 a little bit more .Net like(+ maybe some performance). I used many codes from 3.0.3 Java. So it is somewhere between 2.9.4 3.0.3 But I didn't think it as a separate branch to evolve on its own path. It is(or I think it is) the final version of 2.9 DIGY -Original Message- From: Christopher Currens [mailto:currens.ch...@gmail.com] Sent: Wednesday, December 28, 2011 9:20 PM To: lucene-net-dev@lucene.apache.org Cc: lucene-net-u...@lucene.apache.org Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g One of the benefits of moving forward with the conversion of the Java Lucene, is that they're using more recent versions of Java that support things like generics and enums, so the direct port is getting more and more like .NET, though not in all respects of course. I'm of the mind, though, that one of the larger annoyances, Iterables, should be converted to Enumerables in the direct port. It makes it a pain to use it in .NET without it inheriting from IEnumerable, since it can't be used in a foreach loop or with linq. Also, since the direct port isn't perfect anyway, it seems a port of the IDEA of iterating would be more in the spirit of what we're trying to accomplish, since the code would pretty much be the same, just with different method names. I sort of got off topic there for a second, but I guess the future of 2.9.4g depends on the extent that it is becoming more .NET like. Obviously, while java is starting to use similar constructs that we have in .NET, it will never be perfect. Admittedly, I haven't looked at 2.9.4g in a little while, so I'm not sure how much it now differs from 3.x, since there's a relatively large change there already. Thanks, Christopher On Thu, Dec 22, 2011 at 9:13 PM, Prescott Nasser wrote: That's a great question - I know a lot of people like the generics, and I don't really want it to disappear. I'd like to keep it in parity with the trunk. But I know we also have a goal of making Lucene.Net more .Net like (further than 2.9.4g), and I don't know how that fits in. We are a pretty small community and I know everyone has some pretty busy schedules so it takes us considerable time to make big progress. Trying to keep three different code bases probably isn't the right way to go. Date: Fri, 23 Dec 2011 13:02:03 +1100From: mitiag...@gmail.com To: lucene-net-u...@lucene.apache.orgSubject: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g I was browsing Roadmap emails from November in Lucene developer list. Itremains unclear in what state Lucene 3 porting is , but my question moreabout 2.9.4g .Is it kind of experimental dead end variation of 2.9.4 with generics ? Am I right in classifying it as more .Net like 2.9.4 which is unrelated to roadmap Lucene 3 porting effort. - Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4708 - Release Date: 12/28/11
[jira] [Commented] (SOLR-2346) Non UTF-8 Text files having other than english texts(Japanese/Hebrew) are no getting indexed correctly.
[ https://issues.apache.org/jira/browse/SOLR-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176548#comment-13176548 ] Uwe Schindler commented on SOLR-2346: - Nice fix, is in-line with the other charset handling e.g. for XML imports using standard request handler. I fixed the incorrect XML handling in solr a year ago and did the same thing to pass the charset to the XML parser as hint. Non UTF-8 Text files having other than english texts(Japanese/Hebrew) are no getting indexed correctly. --- Key: SOLR-2346 URL: https://issues.apache.org/jira/browse/SOLR-2346 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Affects Versions: 1.4.1, 3.1, 4.0 Environment: Solr 1.4.1, Packaged Jetty as servlet container, Windows XP SP1, Machine was booted in Japanese Locale. Reporter: Prasad Deshpande Assignee: Koji Sekiguchi Priority: Critical Fix For: 3.6, 4.0 Attachments: NormalSave.msg, SOLR-2346.patch, SOLR-2346.patch, SOLR-2346.patch, UnicodeSave.msg, sample_jap_UTF-8.txt, sample_jap_non_UTF-8.txt I am able to successfully index/search non-Engilsh files (like Hebrew, Japanese) which was encoded in UTF-8. However, When I tried to index data which was encoded in local encoding like Big5 for Japanese I could not see the desired results. The contents after indexing looked garbled for Big5 encoded document when I searched for all indexed documents. When I index attached non utf-8 file it indexes in following way - result name=response numFound=1 start=0 - doc - arr name=attr_content str�� ��/str /arr - arr name=attr_content_encoding strBig5/str /arr - arr name=attr_content_language strzh/str /arr - arr name=attr_language strzh/str /arr - arr name=attr_stream_size str17/str /arr - arr name=content_type strtext/plain/str /arr str name=iddoc2/str /doc /result /response Here you said it index file in UTF8 however it seems that non UTF8 file gets indexed in Big5 encoding. Here I tried fetching indexed data stream in Big5 and converted in UTF8. String id = (String) resulDocument.getFirstValue(attr_content); byte[] bytearray = id.getBytes(Big5); String utf8String = new String(bytearray, UTF-8); It does not gives expected results. When I index UTF-8 file it indexes like following - doc - arr name=attr_content strマイ ネットワーク/str /arr - arr name=attr_content_encoding strUTF-8/str /arr - arr name=attr_stream_content_type strtext/plain/str /arr - arr name=attr_stream_name strsample_jap_unicode.txt/str /arr - arr name=attr_stream_size str28/str /arr - arr name=attr_stream_source_info strmyfile/str /arr - arr name=content_type strtext/plain/str /arr str name=iddoc2/str /doc So, I can index and search UTF-8 data. For more reference below is the discussion with Yonik. Please find attached TXT file which I was using to index and search. curl http://localhost:8983/solr/update/extract?literal.id=doc1uprefix=attr_fmap.content=attr_contentfmap.div=foo_tboost.foo_t=3commit=truecharset=utf-8; -F myfile=@sample_jap_non_UTF-8 One problem is that you are giving big5 encoded text to Solr and saying that it's UTF8. Here's one way to actually tell solr what the encoding of the text you are sending is: curl http://localhost:8983/solr/update/extract?literal.id=doc1uprefix=attr_fmap.content=attr_contentfmap.div=foo_tboost.foo_t=3commit=true; --data-binary @sample_jap_non_UTF-8.txt -H 'Content-type:text/plain; charset=big5' Now the problem appears that for some reason, this doesn't work... Could you open a JIRA issue and attach your two test files? -Yonik http://lucidimagination.com -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2438) Case Insensitive Search for Wildcard Queries
[ https://issues.apache.org/jira/browse/SOLR-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176654#comment-13176654 ] Erick Erickson commented on SOLR-2438: -- Hmmm, it's clear that reading this patch is confusing. See the writeup at: http://wiki.apache.org/solr/MultitermQueryAnalysis Case Insensitive Search for Wildcard Queries Key: SOLR-2438 URL: https://issues.apache.org/jira/browse/SOLR-2438 Project: Solr Issue Type: Improvement Reporter: Peter Sturge Assignee: Erick Erickson Fix For: 3.6, 4.0 Attachments: SOLR-2438-3x.patch, SOLR-2438-3x.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438_3x.patch This patch adds support to allow case-insensitive queries on wildcard searches for configured TextField field types. This patch extends the excellent work done Yonik and Michael in SOLR-219. The approach here is different enough (imho) to warrant a separate JIRA issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 1377 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/1377/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/solr/build/solr-core/test/5/solrtest-SignatureUpdateProcessorFactoryTest-1325081761619/index/_f.tii Stack Trace: java.io.IOException: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/solr/build/solr-core/test/5/solrtest-SignatureUpdateProcessorFactoryTest-1325081761619/index/_f.tii at org.apache.lucene.store.FSDirectory.deleteFile(FSDirectory.java:296) at org.apache.lucene.store.MockDirectoryWrapper.deleteFile(MockDirectoryWrapper.java:392) at org.apache.lucene.store.MockDirectoryWrapper.crash(MockDirectoryWrapper.java:217) at org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:556) at org.apache.solr.SolrTestCaseJ4.closeDirectories(SolrTestCaseJ4.java:82) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:290) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:72) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:310) at org.apache.lucene.util.LuceneTestCase.checkResourcesAfterClass(LuceneTestCase.java:349) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:278) Build Log (for compile errors): [...truncated 14696 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1369 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1369/ 1 tests failed. REGRESSION: org.apache.solr.search.TestRealTimeGet.testStressGetRealtime Error Message: java.lang.AssertionError: Some threads threw uncaught exceptions! Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:657) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:86) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:685) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:629) Build Log (for compile errors): [...truncated 12089 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 11949 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/11949/
No tests ran.
Build Log (for compile errors):
[...truncated 3058 lines...]
[javac] public Collection getFileNames() throws IOException {
[javac] ^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/core/IndexDeletionPolicyWrapper.java:157:
warning: getFileNames() in
org.apache.solr.core.IndexDeletionPolicyWrapper.IndexCommitWrapper overrides
getFileNames() in org.apache.lucene.index.IndexCommit; return type requires
unchecked conversion
[javac] found : java.util.Collection
[javac] required: java.util.Collectionjava.lang.String
[javac] public Collection getFileNames() throws IOException {
[javac] ^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/core/IndexDeletionPolicyWrapper.java:211:
warning: getUserData() in
org.apache.solr.core.IndexDeletionPolicyWrapper.IndexCommitWrapper overrides
getUserData() in org.apache.lucene.index.IndexCommit; return type requires
unchecked conversion
[javac] found : java.util.Map
[javac] required: java.util.Mapjava.lang.String,java.lang.String
[javac] public Map getUserData() throws IOException {
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java:173:
warning: [unchecked] unchecked call to add(java.lang.String,T) as a member of
the raw type org.apache.solr.common.util.NamedList
[javac] lst.add(handlerStart,handlerStart);
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java:174:
warning: [unchecked] unchecked call to add(java.lang.String,T) as a member of
the raw type org.apache.solr.common.util.NamedList
[javac] lst.add(requests, numRequests);
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java:175:
warning: [unchecked] unchecked call to add(java.lang.String,T) as a member of
the raw type org.apache.solr.common.util.NamedList
[javac] lst.add(errors, numErrors);
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java:176:
warning: [unchecked] unchecked call to add(java.lang.String,T) as a member of
the raw type org.apache.solr.common.util.NamedList
[javac] lst.add(timeouts, numTimeouts);
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java:177:
warning: [unchecked] unchecked call to add(java.lang.String,T) as a member of
the raw type org.apache.solr.common.util.NamedList
[javac] lst.add(totalTime,totalTime);
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java:178:
warning: [unchecked] unchecked call to add(java.lang.String,T) as a member of
the raw type org.apache.solr.common.util.NamedList
[javac] lst.add(avgTimePerRequest, (float) totalTime / (float)
this.numRequests);
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java:179:
warning: [unchecked] unchecked call to add(java.lang.String,T) as a member of
the raw type org.apache.solr.common.util.NamedList
[javac] lst.add(avgRequestsPerSecond, (float) numRequests*1000 /
(float)(System.currentTimeMillis()-handlerStart));
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java:216:
warning: [unchecked] unchecked conversion
[javac] found : org.apache.solr.util.RefCounted[]
[javac] required:
org.apache.solr.util.RefCountedorg.apache.solr.search.SolrIndexSearcher[]
[javac] searchers = new RefCounted[sourceCores.length];
[javac] ^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/java/org/apache/solr/handler/component/ResponseBuilder.java:320:
warning: [unchecked] unchecked call to add(java.lang.String,T) as a member of
the raw type org.apache.solr.common.util.NamedList
[javac] rsp.getResponseHeader().add( partialResults, Boolean.TRUE );
[javac] ^
[javac]
[jira] [Resolved] (SOLR-2982) Upgrade Apache Commons Codec to version 1.6 in order to add new Beider-Morse Phonetic Matching (BMPM) option
[ https://issues.apache.org/jira/browse/SOLR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-2982. --- Resolution: Fixed Upgrade Apache Commons Codec to version 1.6 in order to add new Beider-Morse Phonetic Matching (BMPM) option Key: SOLR-2982 URL: https://issues.apache.org/jira/browse/SOLR-2982 Project: Solr Issue Type: Improvement Components: Rules, Schema and Analysis, search Reporter: Brooke Schreier Ganz Labels: codec, commons, commons-codec, language, names, phonetic, search, searching, soundalike Fix For: 3.6, 4.0 Attachments: SOLR-2982.patch Apache Commons Codec released version 1.6 of their codec pack in November, 2011. Along with a few bug fixes, 1.6 contains a great new phonetic matching system called Beider-Morse Phonetic Matching (BMPM) that is far superior to the existing phonetic codecs, such as regular soundex, metaphone, caverphone, and so on. BMPM has actually been available for some time, but this is the first port of it to java, and its first commit in the Apache ecosystem. For a lot more information, see here: http://stevemorse.org/phoneticinfo.htm and http://stevemorse.org/phonetics/bmpm.htm BMPM would be a fantastic soundalike tool to help search for personal names (or just surnames) in a Solr/Lucene index, much better than Levenshtein distance for this use case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2988) edismax does not respect pf params using non-tokenized fields
edismax does not respect pf params using non-tokenized fields
-
Key: SOLR-2988
URL: https://issues.apache.org/jira/browse/SOLR-2988
Project: Solr
Issue Type: Bug
Affects Versions: 3.5
Reporter: Hoss Man
for reasons i don't fully understand, edismax ignores fields in the pf param if
those fields are non-tokenized.
Consider this example *dismax* query in Solr 3.5...
{noformat}
http://localhost:8983/solr/select/?debugQuery=truedefType=dismaxqf=name^5+features^3pf=features^2+cat^4q=hard+drive
str name=parsedquery
+((DisjunctionMaxQuery((features:hard^3.0 | name:hard^5.0))
DisjunctionMaxQuery((features:drive^3.0 | name:drive^5.0))
)~2)
DisjunctionMaxQuery((features:hard drive^2.0 | cat:hard drive^4.0))
{noformat}
...compared to the equivalent *edismax* query...
{noformat}
http://localhost:8983/solr/select/?debugQuery=truedefType=edismaxqf=name^5+features^3pf=features^2+cat^4q=hard+drive
str name=parsedquery
+((DisjunctionMaxQuery((features:hard^3.0 | name:hard^5.0))
DisjunctionMaxQuery((features:drive^3.0 | name:drive^5.0))
)~2)
DisjunctionMaxQuery((features:hard drive^2.0))
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 11951 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/11951/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/solr-core/test/6/solrtest-SignatureUpdateProcessorFactoryTest-1325102196221/index/_f.nrm Stack Trace: java.io.IOException: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/solr-core/test/6/solrtest-SignatureUpdateProcessorFactoryTest-1325102196221/index/_f.nrm at org.apache.lucene.store.FSDirectory.deleteFile(FSDirectory.java:296) at org.apache.lucene.store.MockDirectoryWrapper.deleteFile(MockDirectoryWrapper.java:392) at org.apache.lucene.store.MockDirectoryWrapper.crash(MockDirectoryWrapper.java:265) at org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:556) at org.apache.solr.SolrTestCaseJ4.closeDirectories(SolrTestCaseJ4.java:82) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:290) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:72) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:310) at org.apache.lucene.util.LuceneTestCase.checkResourcesAfterClass(LuceneTestCase.java:349) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:278) Build Log (for compile errors): [...truncated 15152 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 11951 - Failure
As far as I can see, this started intermittently failing at the start of Dec (and only on 3x). Anyone have an idea of what changed to cause this? -Yonik http://www.lucidimagination.com On Wed, Dec 28, 2011 at 3:06 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/11951/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/solr-core/test/6/solrtest-SignatureUpdateProcessorFactoryTest-1325102196221/index/_f.nrm Stack Trace: java.io.IOException: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/solr-core/test/6/solrtest-SignatureUpdateProcessorFactoryTest-1325102196221/index/_f.nrm at org.apache.lucene.store.FSDirectory.deleteFile(FSDirectory.java:296) at org.apache.lucene.store.MockDirectoryWrapper.deleteFile(MockDirectoryWrapper.java:392) at org.apache.lucene.store.MockDirectoryWrapper.crash(MockDirectoryWrapper.java:265) at org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:556) at org.apache.solr.SolrTestCaseJ4.closeDirectories(SolrTestCaseJ4.java:82) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:290) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:72) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:310) at org.apache.lucene.util.LuceneTestCase.checkResourcesAfterClass(LuceneTestCase.java:349) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:278) Build Log (for compile errors): [...truncated 15152 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1931) Schema Browser does not scale with large indexes
[ https://issues.apache.org/jira/browse/SOLR-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176796#comment-13176796 ] Erick Erickson commented on SOLR-1931: -- In the trunk (4.x) version, (from Muir) below. I haven't looked at this yet, but being able to get some approximation back from Luke quickly would be a big help. Maybe we can make this happen on trunk? The use-case I'm interested in is the one in which we're really only looking for outrageous numbers of unique terms. Having unique terms per segment would go a long way towards that use-case. *** Is it really necessary to see the 'top level' number of distinct terms summed across all segments? Maybe its good enough to list the information on a per-segment basis. Then it would always be instant-fast: you would just use FieldsEnum api to list all the fields, and for each field call .terms() and then Terms.getUniqueTermCount() Note: getUniqueTermCount won't work (returns -1) for any 3.x segments that haven't yet been upgraded to the 4.0 format. The old 3.x format only allows you to get the uniqueTermCount across all fields in the segment (Fields.getUniqueTermCount), because fields are not clearly separated. Schema Browser does not scale with large indexes Key: SOLR-1931 URL: https://issues.apache.org/jira/browse/SOLR-1931 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 1.4 Reporter: Lance Norskog Priority: Minor The Schema Browser JSP by default causes the Luke handler to scan the world. In large indexes this make the UI useless. On an index with 64m documents 8gb of disk space, the Schema Browser took 6 minutes to open and hogged all disk I/O, making Solr useless. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 11951 - Failure
I will check later, maybe the usual out of disk space problem. -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de Yonik Seeley yo...@lucidimagination.com schrieb: As far as I can see, this started intermittently failing at the start of Dec (and only on 3x). Anyone have an idea of what changed to cause this? -Yonik http://www.lucidimagination.com On Wed, Dec 28, 2011 at 3:06 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/11951/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/solr-core/test/6/solrtest-SignatureUpdateProcessorFactoryTest-1325102196221/index/_f.nrm Stack Trace: java.io.IOException: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/solr-core/test/6/solrtest-SignatureUpdateProcessorFactoryTest-1325102196221/index/_f.nrm at org.apache.lucene.store.FSDirectory.deleteFile(FSDirectory.java:296) at org.apache.lucene.store.MockDirectoryWrapper.deleteFile(MockDirectoryWrapper.java:392) at org.apache.lucene.store.MockDirectoryWrapper.crash(MockDirectoryWrapper.java:265) at org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:556) at org.apache.solr.SolrTestCaseJ4.closeDirectories(SolrTestCaseJ4.java:82) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:290) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:72) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:310) at org.apache.lucene.util.LuceneTestCase.checkResourcesAfterClass(LuceneTestCase.java:349) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:278) Build Log (for compile errors): [...truncated 15152 lines...] _ To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org _ To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2989) Solr admin (Luke request handler) doesn't order the fields alphabetically
Solr admin (Luke request handler) doesn't order the fields alphabetically - Key: SOLR-2989 URL: https://issues.apache.org/jira/browse/SOLR-2989 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 3.6, 4.0 Environment: all Reporter: Erick Erickson Priority: Minor It's always bugged me that the fields list for admin/schema browser haven't been alphabetical. We have users who have 100s of fields and it's hard to orient in an unordered list. I'll attach a patch momentarily that starts moves toward this. The thing I need someone to render judgement on is whether implementing the Comparable interface on SchemaField and FieldType are in any way dangerous. Note that they only compare on name, secondary and tertiary sources are unnecessary I think. The other interesting bit is that the list of fields is actually (apparently) fetched in two stages. The first stage gets the ones in the schema and the second one gets dynamic fields that have been realized. So the fields section actually has two separate ordered sections. Which is kind of ugly, but given the new admin interface coming in 4.x I don't feel the urge to fix this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2989) Solr admin (Luke request handler) doesn't order the fields alphabetically
[ https://issues.apache.org/jira/browse/SOLR-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-2989: - Attachment: SOLR-2989.patch First cut at a patch. This is for 3x because that's where I happened to be working, but if we carry this forward, I can put it on trunk to I assume. Solr admin (Luke request handler) doesn't order the fields alphabetically - Key: SOLR-2989 URL: https://issues.apache.org/jira/browse/SOLR-2989 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 3.6, 4.0 Environment: all Reporter: Erick Erickson Priority: Minor Attachments: SOLR-2989.patch It's always bugged me that the fields list for admin/schema browser haven't been alphabetical. We have users who have 100s of fields and it's hard to orient in an unordered list. I'll attach a patch momentarily that starts moves toward this. The thing I need someone to render judgement on is whether implementing the Comparable interface on SchemaField and FieldType are in any way dangerous. Note that they only compare on name, secondary and tertiary sources are unnecessary I think. The other interesting bit is that the list of fields is actually (apparently) fetched in two stages. The first stage gets the ones in the schema and the second one gets dynamic fields that have been realized. So the fields section actually has two separate ordered sections. Which is kind of ugly, but given the new admin interface coming in 4.x I don't feel the urge to fix this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-2989) Solr admin (Luke request handler) doesn't order the fields alphabetically
[ https://issues.apache.org/jira/browse/SOLR-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-2989: Assignee: Erick Erickson Solr admin (Luke request handler) doesn't order the fields alphabetically - Key: SOLR-2989 URL: https://issues.apache.org/jira/browse/SOLR-2989 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 3.6, 4.0 Environment: all Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor Attachments: SOLR-2989.patch It's always bugged me that the fields list for admin/schema browser haven't been alphabetical. We have users who have 100s of fields and it's hard to orient in an unordered list. I'll attach a patch momentarily that starts moves toward this. The thing I need someone to render judgement on is whether implementing the Comparable interface on SchemaField and FieldType are in any way dangerous. Note that they only compare on name, secondary and tertiary sources are unnecessary I think. The other interesting bit is that the list of fields is actually (apparently) fetched in two stages. The first stage gets the ones in the schema and the second one gets dynamic fields that have been realized. So the fields section actually has two separate ordered sections. Which is kind of ugly, but given the new admin interface coming in 4.x I don't feel the urge to fix this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 11951 - Failure
Sorry, misunderstood the mail. Jenkins is fine, it’s a test problem occurring sometimes. Last run was fine. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Wednesday, December 28, 2011 9:27 PM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 11951 - Failure I will check later, maybe the usual out of disk space problem. -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de Yonik Seeley yo...@lucidimagination.com schrieb: As far as I can see, this started intermittently failing at the start of Dec (and only on 3x). Anyone have an idea of what changed to cause this? -Yonik http://www.lucidimagination.com http://www.lucidimagination.com On Wed, Dec 28, 2011 at 3:06 PM, Apache Jenkins Server mailto:jenk...@builds.apache.org jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/11951 https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/11951/ 2 tests failed. FAILED: http:// junit.framework.TestSuite.org junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/solr-core/test/6/solrtest-SignatureUpdateProcessorFactoryTest-1325102196221/index/_f.nrm Stack Trace: java.io.IOException: Cannot delete /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/solr-core/test/6/solrtest-SignatureUpdateProcessorFactoryTest-1325102196221/index/_f.nrm at org.apache.lucene.store.FSDirectory.deleteFile(FSDirectory.java:296) at org.apache.lucene.store.MockDirectoryWrapper.deleteFile(MockDirectoryWrapper.java:392) at org.apache.lucene.store.MockDirectoryWrapper.crash(MockDirectoryWrapper.java:265) at org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:556) at org.apache.solr.SolrTestCaseJ4.closeDirectories(SolrTestCaseJ4.java:82) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:290) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:72) FAILED: http:// junit.framework.TestSuite.org junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: directory of test was not closed, opened from: org.apache.solr.core.MockDirectoryFactory.open(MockDirectoryFactory.java:34) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:310) at org.apache.lucene.util.LuceneTestCase.checkResourcesAfterClass(LuceneTestCase.java:349) at org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:278) Build Log (for compile errors): [...truncated 15152 lines...] _ To unsubscribe, e-mail: mailto:dev-unsubscr...@lucene.apache.org dev-unsubscr...@lucene.apache.org For additional commands, e-mail: mailto:dev-h...@lucene.apache.org dev-h...@lucene.apache.org _ To unsubscribe, e-mail: mailto:dev-unsubscr...@lucene.apache.org dev-unsubscr...@lucene.apache.org For additional commands, e-mail: mailto:dev-h...@lucene.apache.org dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2947) DIH caching bug - EntityRunner destroys child entity processor
[ https://issues.apache.org/jira/browse/SOLR-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-2947: --- Attachment: SOLR-2947.patch Ok. here is the patch, which fixes issue with destroy() and problem with multiple threads and CachedSqlEntityProcessor. h3.Code h4.Context.java, ContextImpl.java * removed SCOPE_DOC constant. I can't find any usages. Old impl isn't thread safe. We can implement it thread safe if you want. Let me know if it's necessary. * Pay attention that ContextImpl.putVal() *ignores the scope provided*. It should be tracked separately let me know if you like me to raise it. h4.DataImporter.java I added DocBuilder.destroy() to stop thread pool after all work is done. I'm bothered by testCase's warns about thread leaks h4.DIHCacheSupport.java it just introduces a getter. But I generated diff against uncommitted SOLR-2961, so line numbers can be wrong, let me know I re-diff it. h4.DocBuilder.java * EntityRunner stops create EntityProcessors and obtains it from constructor args * proper destroying EntityProcessors * EntityRunner.docWrapper is removed as not-thread-safe. it's passed explicitly by method arguments * EntityRunner.entityEnded was't thread-safe too. moved into ThreadedEntityProcessorWrapper * object instantiating was drastically amended to be threadsafe ** single EntityRunner per Entity ** single EntityProcessor per EntityRunner ** N ThreadedEntityProcessorWrapper per EntityRunner uses its' EntityProcessor as delegate ** where N is number of threads specified at root entity (threads attr is prohibited for child entities) ** ThreadedEntityProcessorWrapper are numbered by their positions in EntityRunner's tepw list ** parent entity's ThreadedEntityProcessorWrapper always hits children's tepw with the same number as its' own * parent entity's ThreadedEntityProcessorWrapper always hits children's tepw by plain Java synchronous call (w/o thread pool) h4.EntityProcessor.java,EntityProcessorBase.java isPaged() property has been introduced h4.EntityProcessorWrapper.java protected transformRow() has been extracted from applyTransformer(). I need to reuse transformers logic for the paged flow but applyTransformer() has side-effect on rowcache field. h4.ThreadedEntityProcessorWrapper.java in addition to all refactorings above (instantiating and field move). it contains the core idea of multithred cached entity processor: * after tepw obtains access to thread-unaware delegate entityProcessor it need to pull whole page - all children records belong to the current parent, * whole page is transformed and put into tepw.rowcahce, where they will be pulled later by the parent entity tepw h3.Tests h4.TestThreaded.java added full space test for CachedSqlEP for no, 1, 2, 10 (keep in mind 1 thread don't equal to no-threads) h4.TestEphemeralCache.java add double destroy() check EntityProcessors h4.dataimport-cache-ephemeral.xml specifies 10 threads and add double destroy() EntityProcessors DIH caching bug - EntityRunner destroys child entity processor -- Key: SOLR-2947 URL: https://issues.apache.org/jira/browse/SOLR-2947 Project: Solr Issue Type: Sub-task Components: contrib - DataImportHandler Affects Versions: 4.0 Reporter: Mikhail Khludnev Labels: noob Fix For: 4.0 Attachments: SOLR-2947.patch, SOLR-2947.patch, SOLR-2947.patch, dih-cache-destroy-on-threads-fix.patch, dih-cache-threads-enabling-bug.patch My intention is fix multithread import with SQL cache. Here is the 2nd stage. If I enable DocBuilder.EntityRunner flow even for single thread, it breaks the pretty basic functionality: parent-child join. the reason is [line 473 entityProcessor.destroy();|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DocBuilder.java?revision=1201659view=markup] breaks children entityProcessor. see attachement comments for more details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: My role
Erick, I want to fix good old DIH multi-threading issue. It doesn't work at all. I've decided to start after SOLR-2382 is committed. Firstly I've found two minor issues introduced by SOLR-2382: - SOLR-2933 - It has patch polished by James D; - SOLR-2947 - I attached fix for the minor subject issue. It was reviewed by James. And I just attached patch which cover multi-threading _too_. Perhaps it's better to attach it to the separate issue. Let me know. I suppose it's worth to move these two forward, and multi-threading fix too. And btw, then I'll be able to cover one more minor SOLR-2961. Regards On Sat, Dec 17, 2011 at 11:46 PM, Erick Erickson erickerick...@gmail.comwrote: I've been wondering what to do with this committer status thing. When one has reached my age, the prospect of understanding a code base as complex and one that has been worked on by such awesome people is daunting. To quote Robert Heinlein (Time Enough for Love, one of the chapters titled The Notebooks of Lazarus Long) It's amazing how much mature wisdom resembles being too tired. I've never been able to figure out whether how much means the degree to which or the quantity of. I suppose they're both applicable. Anyway, one of the things that's bothered me a bit is the patches people submit that languish. Believe me, I understand that most of the people who are actively involved as committers are doing some really great and fundamental improvements to Lucene/Solr and I'm in awe of their efforts; it's not like other committers have lots of time to spare and are just lazy. But it occurred to me that there's a role for someone to shepherd patches submitted by people who are *not* committers through the process. Or close them as interesting but not something we should add. So, the long and short of it is that I'm volunteering for that role. I expect to lean heavily on the othes to give thumbs-up/thumbs-down here. Don't get me wrong, I'll look over the patches too, but don't be surprised by comments on JIRAs like what do y'all think? Kill or commit?. I have a day job too, so this won't happen all at once. But I've been amazed by how much gets accomplished by steady effort. Besides, it's winter in Michigan. So anybody who has favorite JIRAs that they think are particularly worthwhile, please let me know and I'll at least put them on my list. Let me know your thoughts Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Sincerely yours Mikhail Khludnev Lucid Certified Apache Lucene/Solr Developer Grid Dynamics http://www.griddynamics.com mkhlud...@griddynamics.com
Lucene-2987: lowercase conjunctions
Howdy, I am new to the Lucene project. I started looking at LUCENE-2987https://issues.apache.org/jira/browse/LUCENE-2987. It appears the QueryParser accepts a Conjunction OR and AND, but not the lowercase version. Is this something that needs to be changed with the grammar to accept these as lowercase as well? Also it currently throws a Null pointer exception. What would be the correct error to throw? -- Joe Cabrera
Re: My role
Mikhail: Fair warning. I know nothing, zero, zilch about DIH so as far as code reviews etc, I can do some superficial stuff, but a deep understanding of DIH is not something I can provide. What I can do is help nudge it along, test, do the gruntwork that goes with actually checking something in. Here's what I propose (and I confess I haven't looked at the bugs yet tonight, I won't have time until tomorrow). Let's get on those bugs, and nudge them along. We can gently prompt the people who *do* know to provide some guidance and then we can see if we can get these committed. It'll take some persistence on your part, what I'm hoping most to provide is closure when a consensus is reached that they're ready to commit. And thanks for being willing to work on the *hard* parts. Threading is notorious for having ugly, hard-to-find bugs Best Erick On Wed, Dec 28, 2011 at 5:23 PM, Mikhail Khludnev mkhlud...@griddynamics.com wrote: Erick, I want to fix good old DIH multi-threading issue. It doesn't work at all. I've decided to start after SOLR-2382 is committed. Firstly I've found two minor issues introduced by SOLR-2382: - SOLR-2933 - It has patch polished by James D; - SOLR-2947 - I attached fix for the minor subject issue. It was reviewed by James. And I just attached patch which cover multi-threading _too_. Perhaps it's better to attach it to the separate issue. Let me know. I suppose it's worth to move these two forward, and multi-threading fix too. And btw, then I'll be able to cover one more minor SOLR-2961. Regards On Sat, Dec 17, 2011 at 11:46 PM, Erick Erickson erickerick...@gmail.com wrote: I've been wondering what to do with this committer status thing. When one has reached my age, the prospect of understanding a code base as complex and one that has been worked on by such awesome people is daunting. To quote Robert Heinlein (Time Enough for Love, one of the chapters titled The Notebooks of Lazarus Long) It's amazing how much mature wisdom resembles being too tired. I've never been able to figure out whether how much means the degree to which or the quantity of. I suppose they're both applicable. Anyway, one of the things that's bothered me a bit is the patches people submit that languish. Believe me, I understand that most of the people who are actively involved as committers are doing some really great and fundamental improvements to Lucene/Solr and I'm in awe of their efforts; it's not like other committers have lots of time to spare and are just lazy. But it occurred to me that there's a role for someone to shepherd patches submitted by people who are *not* committers through the process. Or close them as interesting but not something we should add. So, the long and short of it is that I'm volunteering for that role. I expect to lean heavily on the othes to give thumbs-up/thumbs-down here. Don't get me wrong, I'll look over the patches too, but don't be surprised by comments on JIRAs like what do y'all think? Kill or commit?. I have a day job too, so this won't happen all at once. But I've been amazed by how much gets accomplished by steady effort. Besides, it's winter in Michigan. So anybody who has favorite JIRAs that they think are particularly worthwhile, please let me know and I'll at least put them on my list. Let me know your thoughts Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Sincerely yours Mikhail Khludnev Lucid Certified Apache Lucene/Solr Developer Grid Dynamics - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1931) Schema Browser does not scale with large indexes
[ https://issues.apache.org/jira/browse/SOLR-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176961#comment-13176961 ] Otis Gospodnetic commented on SOLR-1931: Is that actually true? What if one is looking at a completely optimized index? Schema Browser does not scale with large indexes Key: SOLR-1931 URL: https://issues.apache.org/jira/browse/SOLR-1931 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 1.4 Reporter: Lance Norskog Priority: Minor The Schema Browser JSP by default causes the Luke handler to scan the world. In large indexes this make the UI useless. On an index with 64m documents 8gb of disk space, the Schema Browser took 6 minutes to open and hogged all disk I/O, making Solr useless. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2802) Toolkit of UpdateProcessors for modifying document values
[ https://issues.apache.org/jira/browse/SOLR-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-2802: --- Attachment: SOLR-2802_update_processor_toolkit.patch Lance: see my 01/Oct/11 comment responding to Erik's nearly identical question (re: scripting) Updated patch adds some more tools to the tool box... * HTMLStripFieldUpdateProcessorFactory * FirstFieldValueUpdateProcessorFactory * LastFieldValueUpdateProcessorFactory * MinFieldValueUpdateProcessorFactory * MaxFieldValueUpdateProcessorFactory The last 4 are subclasses of a new intermediate base class FieldValueSubsetUpdateProcessorFactory designed to make it easy to write subclasses that want to look at all of the values for a field as a Collection, and then return some subset of those values. (in these 4 cases, the subset is always a collection containing a single value) Working with this patch today was he first time i didn't feel like i needed to tweak the existing base classes, which has me starting to think that the API is probably gelled enough for mass consumption. I'd really like to get some more voices chiming in on what they think of the field selector configuration schema so we can move forward on getting what's here committed on trunk, and then iteratively work on adding more concrete subclasses until we're *really* sure that this API makes sense for people to use when writing subclasses, and then look at backporting to 3x. anyone have any opinions on the syntax? Toolkit of UpdateProcessors for modifying document values - Key: SOLR-2802 URL: https://issues.apache.org/jira/browse/SOLR-2802 Project: Solr Issue Type: New Feature Reporter: Hoss Man Attachments: SOLR-2802_update_processor_toolkit.patch, SOLR-2802_update_processor_toolkit.patch, SOLR-2802_update_processor_toolkit.patch Frequently users ask about questions about things where the answer is you could do it with an UpdateProcessor but the number of our of hte box UpdateProcessors is generally lacking and there aren't even very good base classes for the common case of manipulating field values when adding documents -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3655) Add Maven artifact checks to dev-tools/scripts/smokeTestRelease.py
[ https://issues.apache.org/jira/browse/LUCENE-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176998#comment-13176998 ] Steven Rowe commented on LUCENE-3655: - bq. I don't know of any survey's about what's included and what isn't in Python. There's the docs for python's standard library (http://docs.python.org/library/) - I guess that's the LCD. The list of modules distributed with Python is here: [http://docs.python.org/modindex.html]. libxml2 isn't on this list. xml.etree.ElementTree is, though, so I've rewritten the patch to use it instead of libxml2. Add Maven artifact checks to dev-tools/scripts/smokeTestRelease.py -- Key: LUCENE-3655 URL: https://issues.apache.org/jira/browse/LUCENE-3655 Project: Lucene - Java Issue Type: Task Components: general/build Affects Versions: 3.5 Reporter: Steven Rowe Assignee: Steven Rowe Priority: Minor Attachments: LUCENE-3655.patch smokeTestRelease.py should examine the Maven artifacts in a Lucene/Solr release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3655) Add Maven artifact checks to dev-tools/scripts/smokeTestRelease.py
[ https://issues.apache.org/jira/browse/LUCENE-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3655: Attachment: LUCENE-3655.patch Modified the patch to use the xml.etree.ElementTree module, which is part of the base Python distribution, instead of the libxml2 module, which is not. On Cygwin, which I use, Python is at v2.6, which doesn't include xml.etree.ElementTree v1.3, so the XPath support doesn't include attribute predicates; as a result, I had to break XPath queries where attribute checks are needed and perform them with code. Add Maven artifact checks to dev-tools/scripts/smokeTestRelease.py -- Key: LUCENE-3655 URL: https://issues.apache.org/jira/browse/LUCENE-3655 Project: Lucene - Java Issue Type: Task Components: general/build Affects Versions: 3.5 Reporter: Steven Rowe Assignee: Steven Rowe Priority: Minor Attachments: LUCENE-3655.patch, LUCENE-3655.patch smokeTestRelease.py should examine the Maven artifacts in a Lucene/Solr release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
Oh, I see now, we need to import the issues as well as the changesets. I
guess I can just start to work on the Lucene 3.0.3 issues on trunk until
they are imported?
-r
On Wed, Dec 28, 2011 at 5:22 PM, Prescott Nasser geobmx...@hotmail.comwrote:
That's 40 issues that the Java Lucene team tagged as needed for 3.0.3
release (so they are all closed atm) I will try to port many/most of these
over this week into our JIRA so we can track them for ourselves.
From: geobmx...@hotmail.com
To: lucene-net-...@lucene.apache.org Date: Wed, 28 Dec 2011 17:21:39
-0800 Subject: RE: [Lucene.Net] Merge 3.0.3 into trunk and other forward
progress40 issues:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+LUCENE+AND+fixVersion+%3D+%223.0.3%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide
Date: Wed, 28 Dec 2011 15:18:22 -0800 From:
codekai...@gmail.com To: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
I'm not that proficient in JIRA yet, and can only find 22 open
issues outstanding. Is this correct, or am I missing something?
-r On Fri, Dec 23, 2011 at 2:38 PM, Prescott Nasser wrote:
You can look at the jira issues for Java lucene 3.0.3 and submit patches
for 2.9.4g that will bring it up. Worst case is well keep trying to
maintain a line by line and the g. Best case is we can use g as a jump
point to make it even more .net like and whatever work you do will
help usthere as well Sent from my Windows Phone
From: Rory PlaireSent:
12/23/2011 2:27 PMTo: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
So, if there was a very-occasional contributor who wanted to
put some timeinto the project this weekend, is there a way to do it
at this time?I'm only interested in the generics port as well as
making sure that thetranslation offers (at least one-way)
compatibility with Lucene indexes.-r On Fri, Dec 23,
2011 at 1:32 PM, Prescott Nasser wrote:I don't know if
we should do that - the generics is quite different from the line
by line port. I would vote we do it personally - I know othersare
not ok with it. What say other people?
Sent from my Windows Phone
From: Scott Lombard Sent: 12/23/2011 11:21 AM To:
lucene-net-...@lucene.apache.org Subject: RE: [Lucene.Net] Merge
3.0.3 into trunk and other forwardprogress The
Anonymous class issue is a readability issue not a functional change.
So the release could go forward without it. The work should be continued
in the 3.0.3 version. Prescott are you
planning on merging the 2.9.4g into the trunk then3.0.3?
Scott -Original
Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com]
Sent: Thursday, December 22, 2011 4:37 PM To:
lucene-net-...@lucene.apache.org Subject: RE: [Lucene.Net]
Merge 3.0.3 into trunk and other forward progress
Im not as familiar with the g branch - the notice issue is
current, seems like the general incubator has been digging
everyone for it lately. Im not sure about the anon or
the generics unfortunately Sent from my Windows Phone
From: Rory Plaire
Sent: 12/22/2011 12:58 PM To:
lucene-net-...@lucene.apache.org Subject: Re: [Lucene.Net]
Merge 3.0.3 into trunk and other forward progress
I was just looking at the issues for 2.9.4g since I have a
bit of time to put against them in the coming week. They are here:
https://issues.apache.org/jira/browse/LUCENENET/fixforversion/
12316479. Are these current? If so I can just keep going in the
direction DIGY set to help close them. -r
On Thu, Dec 22, 2011 at 10:12 AM, michael herndon
mhern...@wickedsoftware.net wrote:+1 I believe
you tagged the latest during release. Code be reverted
+or a new branch to create a patch for 2.9.4 if something
major happens since we have scm in place, so I think merging it
would not be damaging in any way. for the
2.9.4g branch, I would do a quick scan to see if there are any
outstanding tickets or input from DIGY or anyone else who
put in major time on that branch. If there are things that
are outstanding, throw together a quick list that
people can pull from and work through. I can throw
up some tweets and point towards this thread if you would like.
- Michael On Thu,
Dec 22, 2011 at 12:55 PM, Prescott
RE: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
Yeah that would work
Sent from my Windows Phone
From: Rory Plaire
Sent: 12/28/2011 10:05 PM
To: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
Oh, I see now, we need to import the issues as well as the changesets. I
guess I can just start to work on the Lucene 3.0.3 issues on trunk until
they are imported?
-r
On Wed, Dec 28, 2011 at 5:22 PM, Prescott Nasser geobmx...@hotmail.comwrote:
That's 40 issues that the Java Lucene team tagged as needed for 3.0.3
release (so they are all closed atm) I will try to port many/most of these
over this week into our JIRA so we can track them for ourselves.
From: geobmx...@hotmail.com
To: lucene-net-...@lucene.apache.org Date: Wed, 28 Dec 2011 17:21:39
-0800 Subject: RE: [Lucene.Net] Merge 3.0.3 into trunk and other forward
progress40 issues:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+LUCENE+AND+fixVersion+%3D+%223.0.3%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide
Date: Wed, 28 Dec 2011 15:18:22 -0800 From:
codekai...@gmail.com To: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
I'm not that proficient in JIRA yet, and can only find 22 open
issues outstanding. Is this correct, or am I missing something?
-r On Fri, Dec 23, 2011 at 2:38 PM, Prescott Nasser wrote:
You can look at the jira issues for Java lucene 3.0.3 and submit patches
for 2.9.4g that will bring it up. Worst case is well keep trying to
maintain a line by line and the g. Best case is we can use g as a jump
point to make it even more .net like and whatever work you do will
help usthere as well Sent from my Windows Phone
From: Rory PlaireSent:
12/23/2011 2:27 PMTo: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Merge 3.0.3 into trunk and other forward progress
So, if there was a very-occasional contributor who wanted to
put some timeinto the project this weekend, is there a way to do it
at this time?I'm only interested in the generics port as well as
making sure that thetranslation offers (at least one-way)
compatibility with Lucene indexes.-r On Fri, Dec 23,
2011 at 1:32 PM, Prescott Nasser wrote:I don't know if
we should do that - the generics is quite different from the line
by line port. I would vote we do it personally - I know othersare
not ok with it. What say other people?
Sent from my Windows Phone
From: Scott Lombard Sent: 12/23/2011 11:21 AM To:
lucene-net-...@lucene.apache.org Subject: RE: [Lucene.Net] Merge
3.0.3 into trunk and other forwardprogress The
Anonymous class issue is a readability issue not a functional change.
So the release could go forward without it. The work should be continued
in the 3.0.3 version. Prescott are you
planning on merging the 2.9.4g into the trunk then3.0.3?
Scott -Original
Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com]
Sent: Thursday, December 22, 2011 4:37 PM To:
lucene-net-...@lucene.apache.org Subject: RE: [Lucene.Net]
Merge 3.0.3 into trunk and other forward progress
Im not as familiar with the g branch - the notice issue is
current, seems like the general incubator has been digging
everyone for it lately. Im not sure about the anon or
the generics unfortunately Sent from my Windows Phone
From: Rory Plaire
Sent: 12/22/2011 12:58 PM To:
lucene-net-...@lucene.apache.org Subject: Re: [Lucene.Net]
Merge 3.0.3 into trunk and other forward progress
I was just looking at the issues for 2.9.4g since I have a
bit of time to put against them in the coming week. They are here:
https://issues.apache.org/jira/browse/LUCENENET/fixforversion/
12316479. Are these current? If so I can just keep going in the
direction DIGY set to help close them. -r
On Thu, Dec 22, 2011 at 10:12 AM, michael herndon
mhern...@wickedsoftware.net wrote:+1 I believe
you tagged the latest during release. Code be reverted
+or a new branch to create a patch for 2.9.4 if something
major happens since we have scm in place, so I think merging it
would not be damaging in any way. for the
2.9.4g branch, I would do a quick scan to see if there are any
outstanding tickets or input from DIGY or anyone else who
put in major time on that branch. If there are things that
are outstanding, throw
