[jira] [Updated] (SOLR-2503) UIMA: feature value map to dynamicField
[ https://issues.apache.org/jira/browse/SOLR-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2503: - Attachment: SOLR-2503.patch > UIMA: feature value map to dynamicField > --- > > Key: SOLR-2503 > URL: https://issues.apache.org/jira/browse/SOLR-2503 > Project: Solr > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2503.patch > > > I think "a value of feature maps to a dynamicField" is a nice to have > function. > http://www.lucidimagination.com/search/document/983a059d6d370ce/uima_fieldmappings_and_solr_dynamicfield -- This message is automatically generated by JIRA. 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-1899) dates prior to 1000AD are not formatted properly in responses
[ https://issues.apache.org/jira/browse/SOLR-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030272#comment-13030272 ] Hoss Man commented on SOLR-1899: Status update. After doing some more research: * it seems pretty clear that SimpleDateFormat is fundamentally incapable of formatting negative years (other then using an Era string). * the parseDateTime/printDateTime methods in javax.xml.bind.DatatypeConverter *should* be the perfect solution -- they specifically exist for dealing with XSD dates. But in testing they seem to be completely broken as far as the milliseconds and the requirement that "The fractional second string, if present, must not end in '0';" * based on all the recommendations I found online, i started investigated JodaTime. It has an ISODateTimeFormat factory class that looked promising, but it doesn't seem to support any implementations that are designed for dealing with the canonical form, nor did i have much look using the JodaTime DateTimeFormatterBuilder API to construct one. details are here: https://sourceforge.net/projects/joda-time/forums/forum/337835/topic/4519752 At this point, barring some really awesome insights from anyone else or the JodaTime forum, I'm thinking that (as much as i hate it) hand rolled date parsing/formatting code may be the way to go once and for all. ugh. > dates prior to 1000AD are not formatted properly in responses > - > > Key: SOLR-1899 > URL: https://issues.apache.org/jira/browse/SOLR-1899 > Project: Solr > Issue Type: Bug >Affects Versions: 1.1.0, 1.2, 1.3, 1.4 >Reporter: Hoss Man >Assignee: Hoss Man > Attachments: SOLR-1899.patch > > > As noted on the mailing list, if a document is added to solr with a date > field such as "0001-01-01T00:00:00Z" then when that document is returned by a > search the year will be improperly formated as "1-01-01T00:00:00Z" -- This message is automatically generated by JIRA. 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-2503) UIMA: feature value map to dynamicField
UIMA: feature value map to dynamicField --- Key: SOLR-2503 URL: https://issues.apache.org/jira/browse/SOLR-2503 Project: Solr Issue Type: New Feature Affects Versions: 3.1 Reporter: Koji Sekiguchi Priority: Minor Fix For: 3.2, 4.0 I think "a value of feature maps to a dynamicField" is a nice to have function. http://www.lucidimagination.com/search/document/983a059d6d370ce/uima_fieldmappings_and_solr_dynamicfield -- This message is automatically generated by JIRA. 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] [Resolved] (SOLR-2436) move uimaConfig to under the uima's update processor in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi resolved SOLR-2436. -- Resolution: Fixed trunk: Committed revision 1100435. 3x: Committed revision 1100436. > move uimaConfig to under the uima's update processor in solrconfig.xml > -- > > Key: SOLR-2436 > URL: https://issues.apache.org/jira/browse/SOLR-2436 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2436-3.patch, SOLR-2436-multi-map.patch, > SOLR-2436-multi-map.patch, SOLR-2436.patch, SOLR-2436.patch, SOLR-2436.patch, > SOLR-2436.patch, SOLR-2436_2.patch > > > Solr contrib UIMA has its config just beneath . I think it should > move to uima's update processor tag. -- This message is automatically generated by JIRA. 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-2436) move uimaConfig to under the uima's update processor in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2436: - Attachment: SOLR-2436-multi-map.patch updated patch that includes a test case for multiple mapping. I'll commit shortly. > move uimaConfig to under the uima's update processor in solrconfig.xml > -- > > Key: SOLR-2436 > URL: https://issues.apache.org/jira/browse/SOLR-2436 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2436-3.patch, SOLR-2436-multi-map.patch, > SOLR-2436-multi-map.patch, SOLR-2436.patch, SOLR-2436.patch, SOLR-2436.patch, > SOLR-2436.patch, SOLR-2436_2.patch > > > Solr contrib UIMA has its config just beneath . I think it should > move to uima's update processor tag. -- This message is automatically generated by JIRA. 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-trunk - Build # 1554 - Still Failing
Build: https://builds.apache.org/hudson/job/Lucene-trunk/1554/ 27 tests failed. FAILED: org.apache.lucene.util.packed.TestPackedInts.testMultiValuedNRQ Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. REGRESSION: org.apache.lucene.index.TestNorms.testNorms Error Message: /usr/home/hudson/hudson-slave/workspace/Lucene-trunk/checkout/lucene/build/test/1/test2551710192098085700tmp/_1_2.sd (Too many open files in system) Stack Trace: java.io.FileNotFoundException: /usr/home/hudson/hudson-slave/workspace/Lucene-trunk/checkout/lucene/build/test/1/test2551710192098085700tmp/_1_2.sd (Too many open files in system) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.(RandomAccessFile.java:233) at org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput$Descriptor.(SimpleFSDirectory.java:69) at org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput.(SimpleFSDirectory.java:90) at org.apache.lucene.store.NIOFSDirectory$NIOFSIndexInput.(NIOFSDirectory.java:91) at org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:78) at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:345) at org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:380) at org.apache.lucene.index.codecs.mockrandom.MockRandomCodec.fieldsProducer(MockRandomCodec.java:233) at org.apache.lucene.index.PerFieldCodecWrapper$FieldsReader.(PerFieldCodecWrapper.java:113) at org.apache.lucene.index.PerFieldCodecWrapper.fieldsProducer(PerFieldCodecWrapper.java:210) at org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java:130) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:493) at org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:634) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3283) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:2960) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:37) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1763) at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:1573) at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:1529) at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:1499) at org.apache.lucene.index.TestNorms.testNorms(TestNorms.java:115) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211) REGRESSION: org.apache.lucene.index.TestParallelReader.testDocument Error Message: /usr/home/hudson/hudson-slave/workspace/Lucene-trunk/checkout/lucene/build/test/1/test1544713647653435065tmp/_0.tvf (Too many open files in system) Stack Trace: java.io.FileNotFoundException: /usr/home/hudson/hudson-slave/workspace/Lucene-trunk/checkout/lucene/build/test/1/test1544713647653435065tmp/_0.tvf (Too many open files in system) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.(RandomAccessFile.java:233) at org.apache.lucene.store.FSDirectory$FSIndexOutput.(FSDirectory.java:448) at org.apache.lucene.store.FSDirectory.createOutput(FSDirectory.java:312) at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:354) at org.apache.lucene.index.TermVectorsTermsWriter.initTermVectorsWriter(TermVectorsTermsWriter.java:100) at org.apache.lucene.index.TermVectorsTermsWriter.finishDocument(TermVectorsTermsWriter.java:119) at org.apache.lucene.index.TermsHash.finishDocument(TermsHash.java:141) at org.apache.lucene.index.DocInverter.finishDocument(DocInverter.java:94) at org.apache.lucene.index.DocFieldProcessor.finishDocument(DocFieldProcessor.java:259) at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:245) at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:327) at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1365) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1230) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1211) at org.apache.lucene.index.TestParallelReader.getDir1(TestParallelReader.java:281) at org.apache.lucene.index.TestParallelReader.testDocument(TestParallelReader.java:93) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.
[jira] [Updated] (SOLR-2436) move uimaConfig to under the uima's update processor in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2436: - Attachment: SOLR-2436-multi-map.patch > move uimaConfig to under the uima's update processor in solrconfig.xml > -- > > Key: SOLR-2436 > URL: https://issues.apache.org/jira/browse/SOLR-2436 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2436-3.patch, SOLR-2436-multi-map.patch, > SOLR-2436.patch, SOLR-2436.patch, SOLR-2436.patch, SOLR-2436.patch, > SOLR-2436_2.patch > > > Solr contrib UIMA has its config just beneath . I think it should > move to uima's update processor tag. -- This message is automatically generated by JIRA. 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-2436) move uimaConfig to under the uima's update processor in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030256#comment-13030256
]
Koji Sekiguchi commented on SOLR-2436:
--
While I was reviewing my requirement:
http://www.lucidimagination.com/search/document/983a059d6d370ce/uima_fieldmappings_and_solr_dynamicfield
I found a bug that's been introduced in this ticket. I'd mentioned it at above
in this thread, but not corrected at the time.
Because a type can have multiple features, the mapping definition:
{code}
org.apache.uima.SentenceAnnotation
coveredText
sentence
{code}
should be:
{code}
org.apache.uima.SentenceAnnotation
coveredText
sentence
{code}
> move uimaConfig to under the uima's update processor in solrconfig.xml
> --
>
> Key: SOLR-2436
> URL: https://issues.apache.org/jira/browse/SOLR-2436
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: SOLR-2436-3.patch, SOLR-2436.patch, SOLR-2436.patch,
> SOLR-2436.patch, SOLR-2436.patch, SOLR-2436_2.patch
>
>
> Solr contrib UIMA has its config just beneath . I think it should
> move to uima's update processor tag.
--
This message is automatically generated by JIRA.
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] [Reopened] (SOLR-2436) move uimaConfig to under the uima's update processor in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi reopened SOLR-2436: -- > move uimaConfig to under the uima's update processor in solrconfig.xml > -- > > Key: SOLR-2436 > URL: https://issues.apache.org/jira/browse/SOLR-2436 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2436-3.patch, SOLR-2436.patch, SOLR-2436.patch, > SOLR-2436.patch, SOLR-2436.patch, SOLR-2436_2.patch > > > Solr contrib UIMA has its config just beneath . I think it should > move to uima's update processor tag. -- This message is automatically generated by JIRA. 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: svn commit: r1099878 - in /lucene/dev/branches/branch_3x: ./ lucene/ lucene/backwards/ lucene/src/java/org/apache/lucene/index/LogMergePolicy.java solr/
: LUCENE-1076: fix AIOOBE when infoStream is on (back port from trunk) would it be worthwhile to add infoStream on/off as a test randomization? (it might not warrant it's own system property, but the test base class could choose to set a stream on all new writers based on a random number) -Hoss - 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 # 7795 - Failure
False failure (test assumes docids don't change on merge) -- I committed a fix. Mike http://blog.mikemccandless.com On Fri, May 6, 2011 at 5:21 PM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7795/ > > 1 tests failed. > REGRESSION: > org.apache.lucene.search.TestTimeLimitingCollector.testTimeoutMultiThreaded > > Error Message: > some threads failed! expected:<50> but was:<45> > > Stack Trace: > junit.framework.AssertionFailedError: some threads failed! expected:<50> but > was:<45> > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1156) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1084) > at > org.apache.lucene.search.TestTimeLimitingCollector.doTestMultiThreads(TestTimeLimitingCollector.java:294) > at > org.apache.lucene.search.TestTimeLimitingCollector.testTimeoutMultiThreaded(TestTimeLimitingCollector.java:266) > > > > > Build Log (for compile errors): > [...truncated 5330 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
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 7795 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7795/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestTimeLimitingCollector.testTimeoutMultiThreaded Error Message: some threads failed! expected:<50> but was:<45> Stack Trace: junit.framework.AssertionFailedError: some threads failed! expected:<50> but was:<45> at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1156) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1084) at org.apache.lucene.search.TestTimeLimitingCollector.doTestMultiThreads(TestTimeLimitingCollector.java:294) at org.apache.lucene.search.TestTimeLimitingCollector.testTimeoutMultiThreaded(TestTimeLimitingCollector.java:266) Build Log (for compile errors): [...truncated 5330 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: jira issues falling off the radar -- "Next" JIRA version
: I suggest we marge "Next" into "3.2" ... Ok, i fixed the few issues that were marked "fixed" in Next (they were all really for 3.1), and merged "Next" into 3.2. David: I *think* that wraps up all of the concerns you pointed out about our Jira version tracking, but please holler if I missed something. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: modularization discussion
+1, +1, +1, +1, +1, +1 - This is just what I've been trying (and seemingly failing) to express. On May 6, 2011, at 4:35 PM, Chris Hostetter wrote: > > : To me, the third camp is just saying the proof is in the pudding. If > : you want to refactor, then go for it. Just make sure everything still > : works, which of course I know people will (but part of that means > : actually running Solr, IMO). Perhaps, more importantly don't get mad > : that if I have only one day a week to work on Lucene/Solr that I spend > : it putting a specific feature in a specific place. Just because > : something can/should be modularized, doesn't mean that a person working > : in that area must do it before they add whatever they were working on. > : For instance, if and when function queries are a module, I will add to > : them there and be happy to do so. In the meantime, I will likely add to > : them in Solr if that is something I happen to be interested in at that > : time b/c I can certainly add a new function in a day, but I can't > : refactor the whole module _and_ add my new function in a day. > > +1 > > I want to get that printed on a t-shirt > > the corrolarry issue in my mind... > > I am happily in favor of code reuse and modularization in the abstract, > and when it works in practice i'm plesantly delighted. > > But when people talk about modularization as a goal, and make a laundry > list things in solr that people think should be refactored into modules > (w/o showing specifics of what that module would look like) then i have a > hard time buying into some of these ideas panning out in a way that: > a) is a useful module to people in and of itself > b) doesn't hamstring the evolution/performance in solr. > > To look at "faceting" as a concrete example, there are big the reasons > faceting works so well in Solr: Solr has total control over the > index, knows exactly when the index has changed to rebuild caches, has a > strict schema so it can make sense of field types and > pick faceting algos accordingly, has multi-phase distributed search > approach to get exact counts efficiently across multiple shards, etc... > (and there are still a lot of additional enhancements and improvements > that can be made to take even more advantage of knowledge solr has because > it "owns" the index that we no one has had time to tackle) > > I find it really hard to picture a way that this code could be refactored > into a reusable module in such a way that it could have an API that would > be easily usable outside of Solr -- and when i do get a glimmer of an > inkling of what that might look like, that vision scares me because of how > that API might then "hobble" Solr's ability to leverage it's total control > of the underlying index to add additional performance/features. > > To be crystal clear: I recognize that this is *my* hangup -- I am not > suggesting that "I am short sighted and have little imagination > therefore this code should never be modularized." > > I'm trying to explain why i *personally* am hesitant and sceptical of how > well modularizations of features like like this might actually work in > practice, and why i'm not eager to jump in and contribute on a goal whose > end result is something that i can't fully picture (and when i can picture > it, i'm a little scared by what i see) > > That doesn't mean i'm opposed to it happening -- i would love to live in > the land of candy where houses are made of ginger bread and sugar plums > grow on trees, I'm just too skeptical that such a land exists (or is as > great as legend describes) to go slogging along on an epic journey to try > and reach it -- i'm too old for that shit. > > I'm certainly not going to stop anyone else fro going on that quest -- but > i am entitled to voice my skepticism and concerns, just as adventursome > folks are entitled to ignore me. > > > -Hoss > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - Mark Miller lucidimagination.com Lucene/Solr User Conference May 25-26, San Francisco www.lucenerevolution.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2013) ASCIIFoldingFilter => MappingCharFilterFactory as a mapping file
[ https://issues.apache.org/jira/browse/SOLR-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-2013: --- Affects Version/s: (was: Next) Fix Version/s: (was: Next) > ASCIIFoldingFilter => MappingCharFilterFactory as a mapping file > > > Key: SOLR-2013 > URL: https://issues.apache.org/jira/browse/SOLR-2013 > Project: Solr > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Steven Rowe >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.1 > > Attachments: mapping-FoldToASCII.txt, mapping-FoldToASCII.txt > > > Attached is a mapping file to provide the equivalent of ASCIIFoldingFilter > through the MappingCharFilterFactory. > I'm not sure where this should go in the source tree. -- This message is automatically generated by JIRA. 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] [Reopened] (SOLR-2013) ASCIIFoldingFilter => MappingCharFilterFactory as a mapping file
[ https://issues.apache.org/jira/browse/SOLR-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reopened SOLR-2013: > ASCIIFoldingFilter => MappingCharFilterFactory as a mapping file > > > Key: SOLR-2013 > URL: https://issues.apache.org/jira/browse/SOLR-2013 > Project: Solr > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Steven Rowe >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.1 > > Attachments: mapping-FoldToASCII.txt, mapping-FoldToASCII.txt > > > Attached is a mapping file to provide the equivalent of ASCIIFoldingFilter > through the MappingCharFilterFactory. > I'm not sure where this should go in the source tree. -- This message is automatically generated by JIRA. 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] [Resolved] (SOLR-2013) ASCIIFoldingFilter => MappingCharFilterFactory as a mapping file
[ https://issues.apache.org/jira/browse/SOLR-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-2013. Resolution: Fixed > ASCIIFoldingFilter => MappingCharFilterFactory as a mapping file > > > Key: SOLR-2013 > URL: https://issues.apache.org/jira/browse/SOLR-2013 > Project: Solr > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Steven Rowe >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.1 > > Attachments: mapping-FoldToASCII.txt, mapping-FoldToASCII.txt > > > Attached is a mapping file to provide the equivalent of ASCIIFoldingFilter > through the MappingCharFilterFactory. > I'm not sure where this should go in the source tree. -- This message is automatically generated by JIRA. 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-2009) Contrib ant test targets do not respect sys props testcase,testpackage,and testpackageroot
[ https://issues.apache.org/jira/browse/SOLR-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-2009: --- Fix Version/s: (was: Next) 3.1 > Contrib ant test targets do not respect sys props testcase,testpackage,and > testpackageroot > -- > > Key: SOLR-2009 > URL: https://issues.apache.org/jira/browse/SOLR-2009 > Project: Solr > Issue Type: Bug > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 3.1 > > Attachments: SOLR-2009.patch > > > Very annoying using these props with core tests unless you use the junit > target rather than test. Also would be nice if they worked regardless for > future dev. -- This message is automatically generated by JIRA. 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-1316) 3
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1316: --- Fix Version/s: (was: Next) 3.1 Summary: 3 (was: Create autosuggest component) > 3 > - > > Key: SOLR-1316 > URL: https://issues.apache.org/jira/browse/SOLR-1316 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Andrzej Bialecki >Priority: Minor > Fix For: 3.1 > > Attachments: SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, > SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, > SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, > SOLR-1316_3x-2.patch, SOLR-1316_3x.patch, TST.zip, suggest.patch, > suggest.patch, suggest.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > Autosuggest is a common search function that can be integrated > into Solr as a SearchComponent. Our first implementation will > use the TernaryTree found in Lucene contrib. > * Enable creation of the dictionary from the index or via Solr's > RPC mechanism > * What types of parameters and settings are desirable? > * Hopefully in the future we can include user click through > rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. 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-1991) The example target should work from a fresh checkout without running other targets first
[ https://issues.apache.org/jira/browse/SOLR-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1991: --- Fix Version/s: (was: Next) 3.1 > The example target should work from a fresh checkout without running other > targets first > > > Key: SOLR-1991 > URL: https://issues.apache.org/jira/browse/SOLR-1991 > Project: Solr > Issue Type: Bug > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 3.1 > > Attachments: SOLR-1991.patch > > > This broke with the merge I guess. -- This message is automatically generated by JIRA. 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: modularization discussion
: To me, the third camp is just saying the proof is in the pudding. If : you want to refactor, then go for it. Just make sure everything still : works, which of course I know people will (but part of that means : actually running Solr, IMO). Perhaps, more importantly don't get mad : that if I have only one day a week to work on Lucene/Solr that I spend : it putting a specific feature in a specific place. Just because : something can/should be modularized, doesn't mean that a person working : in that area must do it before they add whatever they were working on. : For instance, if and when function queries are a module, I will add to : them there and be happy to do so. In the meantime, I will likely add to : them in Solr if that is something I happen to be interested in at that : time b/c I can certainly add a new function in a day, but I can't : refactor the whole module _and_ add my new function in a day. +1 I want to get that printed on a t-shirt the corrolarry issue in my mind... I am happily in favor of code reuse and modularization in the abstract, and when it works in practice i'm plesantly delighted. But when people talk about modularization as a goal, and make a laundry list things in solr that people think should be refactored into modules (w/o showing specifics of what that module would look like) then i have a hard time buying into some of these ideas panning out in a way that: a) is a useful module to people in and of itself b) doesn't hamstring the evolution/performance in solr. To look at "faceting" as a concrete example, there are big the reasons faceting works so well in Solr: Solr has total control over the index, knows exactly when the index has changed to rebuild caches, has a strict schema so it can make sense of field types and pick faceting algos accordingly, has multi-phase distributed search approach to get exact counts efficiently across multiple shards, etc... (and there are still a lot of additional enhancements and improvements that can be made to take even more advantage of knowledge solr has because it "owns" the index that we no one has had time to tackle) I find it really hard to picture a way that this code could be refactored into a reusable module in such a way that it could have an API that would be easily usable outside of Solr -- and when i do get a glimmer of an inkling of what that might look like, that vision scares me because of how that API might then "hobble" Solr's ability to leverage it's total control of the underlying index to add additional performance/features. To be crystal clear: I recognize that this is *my* hangup -- I am not suggesting that "I am short sighted and have little imagination therefore this code should never be modularized." I'm trying to explain why i *personally* am hesitant and sceptical of how well modularizations of features like like this might actually work in practice, and why i'm not eager to jump in and contribute on a goal whose end result is something that i can't fully picture (and when i can picture it, i'm a little scared by what i see) That doesn't mean i'm opposed to it happening -- i would love to live in the land of candy where houses are made of ginger bread and sugar plums grow on trees, I'm just too skeptical that such a land exists (or is as great as legend describes) to go slogging along on an epic journey to try and reach it -- i'm too old for that shit. I'm certainly not going to stop anyone else fro going on that quest -- but i am entitled to voice my skepticism and concerns, just as adventursome folks are entitled to ignore me. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2502) Add in Examples/Documentation on the new Join functionality
[
https://issues.apache.org/jira/browse/SOLR-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated SOLR-2502:
--
Attachment: SOLR-2502.patch
Here's what I have in mind:
Add in manufacturers documents and then tie the various products we have back
to the manufacturers.
A query then might look like:
http://localhost:8983/solr/select/?q={!join%20from=manu_id_s%20to=id}name:ipod
> Add in Examples/Documentation on the new Join functionality
> ---
>
> Key: SOLR-2502
> URL: https://issues.apache.org/jira/browse/SOLR-2502
> Project: Solr
> Issue Type: Improvement
>Reporter: Grant Ingersoll
>Priority: Minor
> Attachments: SOLR-2502.patch
>
>
> As the title says, add in an example and docs on the new Join functionality
> added via SOLR-2272.
--
This message is automatically generated by JIRA.
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-2502) Add in Examples/Documentation on the new Join functionality
[ https://issues.apache.org/jira/browse/SOLR-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030119#comment-13030119 ] Grant Ingersoll commented on SOLR-2502: --- Docs are started at: http://wiki.apache.org/solr/Join > Add in Examples/Documentation on the new Join functionality > --- > > Key: SOLR-2502 > URL: https://issues.apache.org/jira/browse/SOLR-2502 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Priority: Minor > > As the title says, add in an example and docs on the new Join functionality > added via SOLR-2272. -- This message is automatically generated by JIRA. 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-2502) Add in Examples/Documentation on the new Join functionality
Add in Examples/Documentation on the new Join functionality --- Key: SOLR-2502 URL: https://issues.apache.org/jira/browse/SOLR-2502 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Priority: Minor As the title says, add in an example and docs on the new Join functionality added via SOLR-2272. -- This message is automatically generated by JIRA. 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 # 7791 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7791/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestTimeLimitingCollector.testTimeoutMultiThreaded Error Message: some threads failed! expected:<50> but was:<48> Stack Trace: junit.framework.AssertionFailedError: some threads failed! expected:<50> but was:<48> at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1156) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1084) at org.apache.lucene.search.TestTimeLimitingCollector.doTestMultiThreads(TestTimeLimitingCollector.java:294) at org.apache.lucene.search.TestTimeLimitingCollector.testTimeoutMultiThreaded(TestTimeLimitingCollector.java:266) Build Log (for compile errors): [...truncated 5305 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Improvements to the maven build
: Even "small" things?! It would be a royal pain in the ass to submit an : issue for every last stupid typo, reformat, and minor thing. I would a rough rule of thumb: "if you can describe the problem in fewer bytes then the patch would take, don't bother with a jira issue" if someone says in an email "hey i noticed a typo in these javadocs [URL]" or "hey i think there's an off by one error in Yak.fooBar() because of "<" instead of "<=" you don't need to tell them "thanks for pointing that out, but i can't change that until you create a patch and attach it to jira" if someone creates a patch and sends it in an email (or attaches a new/modified source file) you should usually ask them to attach it to jira. the main differentiator (as i understand it) is not not "size" of contribution, but "significance" ... something that's an obvious bug/mistake/typo once someone points you to a line number can just be fixed. you (the committer) are writing the code to fix a bug pointed out by a contributor -- but when a contributor submits a "significant" chunk of code/functionality, we need Jira to track that they "Grant license to ASF for inclusion in ASF works (as per the Apache License §5)" -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Consolodation of boosts on multivalued fields
After looking for places in the code where boosts are consolidated for
multivalue fields, I found this class:
lucene/src/java/org/apache/lucene/index/FieldInvertState.java
Which has a "float boost" member variable. FieldInvertState seems to
keep track of the index positions of several Fields with the same
name.
I'm considering changing that float to a "Vector" to keep track
of each individual field's boost, but there is a lot of code that
calls FieldInvertState.getBoost(). The excerpts are listed at the end
of this email.
Does anyone have a good idea of how to get FieldInvertState to store
boosts for each field, if that's even the right direction to go?
Calls to FieldInvertState.getBoost():
--
$ ack --java -i 'state\.getBoost'
lucene/contrib/misc/src/java/org/apache/lucene/misc/SweetSpotSimilarity.java
103: * Implemented as state.getBoost() *
117:return state.getBoost() * computeLengthNorm(numTokens);
lucene/contrib/misc/src/test/org/apache/lucene/index/TestFieldNormModifier.java
53: return state.getBoost() * (discountOverlaps ?
state.getLength() - state.getNumOverlap() : state.getLength());
lucene/contrib/misc/src/test/org/apache/lucene/misc/TestLengthNormModifier.java
58:return state.getBoost() * (discountOverlaps ?
state.getLength() - state.getNumOverlap() : state.getLength());
179: return state.getBoost() * (discountOverlaps ?
state.getLength() - state.getNumOverlap() : state.getLength());
lucene/src/java/org/apache/lucene/search/DefaultSimilarity.java
26: * state.getBoost()*lengthNorm(numTerms), where
40:return state.getBoost() * ((float) (1.0 / Math.sqrt(numTerms)));
lucene/src/test/org/apache/lucene/index/TestIndexReaderCloneNorms.java
52: return state.getBoost();
lucene/src/test/org/apache/lucene/index/TestNorms.java
51: return state.getBoost();
lucene/src/test/org/apache/lucene/index/TestOmitTf.java
44:@Override public float computeNorm(FieldInvertState state)
{ return state.getBoost(); }
lucene/src/test/org/apache/lucene/search/TestDisjunctionMaxQuery.java
67: return state.getBoost();
lucene/src/test/org/apache/lucene/search/TestSimilarity.java
47:@Override public float computeNorm(FieldInvertState state)
{ return state.getBoost(); }
lucene/src/test/org/apache/lucene/search/payloads/TestPayloadNearQuery.java
326: return state.getBoost();
lucene/src/test/org/apache/lucene/search/payloads/TestPayloadTermQuery.java
319: return state.getBoost();
On Thu, May 5, 2011 at 11:45 AM, Neil Hooey wrote:
> Currently when you assign boosts to multivalue fields during
> index-time, they are consolidated, and the individual boosts are lost.
>
> There are some relevant cases where the individual boost values are
> important, so I'd like to fix this behaviour.
>
> I've created an issue here, which gives some examples:
> https://issues.apache.org/jira/browse/SOLR-2499
>
> Do you have any ideas of where to get started with this fix, or have
> an idea of how difficult the fix might be?
>
> Thanks,
>
> - Neil
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3078) Add generics to DocumentsWriterDeleteQueue.Node
[ https://issues.apache.org/jira/browse/LUCENE-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3078. --- Resolution: Fixed Fix Version/s: 4.0 Assignee: Uwe Schindler Committed trunk revision: 1100239 > Add generics to DocumentsWriterDeleteQueue.Node > --- > > Key: LUCENE-3078 > URL: https://issues.apache.org/jira/browse/LUCENE-3078 > Project: Lucene - Java > Issue Type: Task >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.0 > > Attachments: LUCENE-3078.patch, LUCENE-3078.patch > > > DocumentsWriterDeleteQueue.Note should be generic as the subclasses hold > different types of items. This generification is a little bit tricks, but the > generics policeman can't wait to fix this *g*. -- This message is automatically generated by JIRA. 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-3078) Add generics to DocumentsWriterDeleteQueue.Node
[ https://issues.apache.org/jira/browse/LUCENE-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029956#comment-13029956 ] Simon Willnauer commented on LUCENE-3078: - Yes Sir Mr. Generics Policeman :D looks good! > Add generics to DocumentsWriterDeleteQueue.Node > --- > > Key: LUCENE-3078 > URL: https://issues.apache.org/jira/browse/LUCENE-3078 > Project: Lucene - Java > Issue Type: Task >Reporter: Uwe Schindler > Attachments: LUCENE-3078.patch, LUCENE-3078.patch > > > DocumentsWriterDeleteQueue.Note should be generic as the subclasses hold > different types of items. This generification is a little bit tricks, but the > generics policeman can't wait to fix this *g*. -- This message is automatically generated by JIRA. 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-3078) Add generics to DocumentsWriterDeleteQueue.Node
[ https://issues.apache.org/jira/browse/LUCENE-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3078: -- Attachment: LUCENE-3078.patch Eclipse compiler warns about one synthetic access$ method on Simon's original code, we should also remove: bq. Access to enclosing constructor DocumentsWriterDeleteQueue.Node(T) is emulated by a synthetic accessor method Fixed in this patch. Eclipse also complains generics wise (raw Node access in ReferenceUpdater declaration, but this is just too picky and cannot be solved because of .class constructs). > Add generics to DocumentsWriterDeleteQueue.Node > --- > > Key: LUCENE-3078 > URL: https://issues.apache.org/jira/browse/LUCENE-3078 > Project: Lucene - Java > Issue Type: Task >Reporter: Uwe Schindler > Attachments: LUCENE-3078.patch, LUCENE-3078.patch > > > DocumentsWriterDeleteQueue.Note should be generic as the subclasses hold > different types of items. This generification is a little bit tricks, but the > generics policeman can't wait to fix this *g*. -- This message is automatically generated by JIRA. 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-3071) PathHierarchyTokenizer adaptation for urls: splits reversed
[
https://issues.apache.org/jira/browse/LUCENE-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029946#comment-13029946
]
Ryan McKinley commented on LUCENE-3071:
---
check:
http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/CHANGES.txt?p2=%2Flucene%2Fdev%2Fbranches%2Fbranch_3x%2Flucene%2FCHANGES.txt&p1=%2Flucene%2Fdev%2Fbranches%2Fbranch_3x%2Flucene%2FCHANGES.txt&r1=1100033&r2=1100032&view=diff&pathrev=1100033
It is on the 3.x branch -- my understanding is that will get merged with the
trunk changes when 4.x is valid.
I *think* this was the resolution of how we will handle changes, but now that
you ask, i am not sure... anyone know what the current CHANGES policy is?
> PathHierarchyTokenizer adaptation for urls: splits reversed
> ---
>
> Key: LUCENE-3071
> URL: https://issues.apache.org/jira/browse/LUCENE-3071
> Project: Lucene - Java
> Issue Type: New Feature
> Components: contrib/analyzers
>Reporter: Olivier Favre
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3071.patch, LUCENE-3071.patch, LUCENE-3071.patch,
> LUCENE-3071.patch, ant.log.tar.bz2
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {{PathHierarchyTokenizer}} should be usable to split urls the a "reversed"
> way (useful for faceted search against urls):
> {{www.site.com}} -> {{www.site.com, site.com, com}}
> Moreover, it should be able to skip a given number of first (or last, if
> reversed) tokens:
> {{/usr/share/doc/somesoftware/INTERESTING/PART}}
> Should give with 4 tokens skipped:
> {{INTERESTING}}
> {{INTERESTING/PART}}
--
This message is automatically generated by JIRA.
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-3071) PathHierarchyTokenizer adaptation for urls: splits reversed
[
https://issues.apache.org/jira/browse/LUCENE-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029944#comment-13029944
]
Olivier Favre commented on LUCENE-3071:
---
It seems you forgot to commit lucene/contrib/CHANGES.txt to describe the new
feature.
Regards
> PathHierarchyTokenizer adaptation for urls: splits reversed
> ---
>
> Key: LUCENE-3071
> URL: https://issues.apache.org/jira/browse/LUCENE-3071
> Project: Lucene - Java
> Issue Type: New Feature
> Components: contrib/analyzers
>Reporter: Olivier Favre
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3071.patch, LUCENE-3071.patch, LUCENE-3071.patch,
> LUCENE-3071.patch, ant.log.tar.bz2
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {{PathHierarchyTokenizer}} should be usable to split urls the a "reversed"
> way (useful for faceted search against urls):
> {{www.site.com}} -> {{www.site.com, site.com, com}}
> Moreover, it should be able to skip a given number of first (or last, if
> reversed) tokens:
> {{/usr/share/doc/somesoftware/INTERESTING/PART}}
> Should give with 4 tokens skipped:
> {{INTERESTING}}
> {{INTERESTING/PART}}
--
This message is automatically generated by JIRA.
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: Improvements to the maven build
On Fri, May 6, 2011 at 9:48 AM, Smiley, David W. wrote: > > On May 4, 2011, at 7:14 PM, Ryan McKinley wrote: > >> As a rule, everything should go through JIRA on its way to svn -- this >> is important so that we have somewhere to point for why we did things. >> Even small things. > > Even "small" things?! It would be a royal pain in the ass to submit an issue > for every last stupid typo, reformat, and minor thing. I would also hope > that if a committer authored a chunk of code that he believed, after the > first iteration has already been committed, could use some "minor" tweak that > lets say improves the clarity of the logic or has a better private method > name, that he could just go ahead and commit the minor tweak. I hope that > you guys are not burdened by JIRA for such things! > Again, I did not mean to make a huge deal out of this -- my reaction to seeing a patch posted as an attachment is "this belongs in JIRA" -- I don't care how trivial it is. If the patch were in the message text, i would feel differently. ryan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3071) PathHierarchyTokenizer adaptation for urls: splits reversed
[
https://issues.apache.org/jira/browse/LUCENE-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029942#comment-13029942
]
Ryan McKinley commented on LUCENE-3071:
---
thanks simon -- sorry about that, i will check for merge help next time.
> PathHierarchyTokenizer adaptation for urls: splits reversed
> ---
>
> Key: LUCENE-3071
> URL: https://issues.apache.org/jira/browse/LUCENE-3071
> Project: Lucene - Java
> Issue Type: New Feature
> Components: contrib/analyzers
>Reporter: Olivier Favre
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3071.patch, LUCENE-3071.patch, LUCENE-3071.patch,
> LUCENE-3071.patch, ant.log.tar.bz2
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {{PathHierarchyTokenizer}} should be usable to split urls the a "reversed"
> way (useful for faceted search against urls):
> {{www.site.com}} -> {{www.site.com, site.com, com}}
> Moreover, it should be able to skip a given number of first (or last, if
> reversed) tokens:
> {{/usr/share/doc/somesoftware/INTERESTING/PART}}
> Should give with 4 tokens skipped:
> {{INTERESTING}}
> {{INTERESTING/PART}}
--
This message is automatically generated by JIRA.
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-3078) Add generics to DocumentsWriterDeleteQueue.Node
[ https://issues.apache.org/jira/browse/LUCENE-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029941#comment-13029941 ] Uwe Schindler commented on LUCENE-3078: --- This compiles without unsafe warnings in javac 1.5 - Eclipse may complain more - but javac 1.5 is what counts for the generics policman. > Add generics to DocumentsWriterDeleteQueue.Node > --- > > Key: LUCENE-3078 > URL: https://issues.apache.org/jira/browse/LUCENE-3078 > Project: Lucene - Java > Issue Type: Task >Reporter: Uwe Schindler > Attachments: LUCENE-3078.patch > > > DocumentsWriterDeleteQueue.Note should be generic as the subclasses hold > different types of items. This generification is a little bit tricks, but the > generics policeman can't wait to fix this *g*. -- This message is automatically generated by JIRA. 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-3078) Add generics to DocumentsWriterDeleteQueue.Node
[ https://issues.apache.org/jira/browse/LUCENE-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3078: -- Attachment: LUCENE-3078.patch Huperduper® generics patch. > Add generics to DocumentsWriterDeleteQueue.Node > --- > > Key: LUCENE-3078 > URL: https://issues.apache.org/jira/browse/LUCENE-3078 > Project: Lucene - Java > Issue Type: Task >Reporter: Uwe Schindler > Attachments: LUCENE-3078.patch > > > DocumentsWriterDeleteQueue.Note should be generic as the subclasses hold > different types of items. This generification is a little bit tricks, but the > generics policeman can't wait to fix this *g*. -- This message is automatically generated by JIRA. 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 # 7780 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7780/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestTimeLimitingCollector.testTimeoutMultiThreaded Error Message: some threads failed! expected:<50> but was:<47> Stack Trace: junit.framework.AssertionFailedError: some threads failed! expected:<50> but was:<47> at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1156) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1084) at org.apache.lucene.search.TestTimeLimitingCollector.doTestMultiThreads(TestTimeLimitingCollector.java:294) at org.apache.lucene.search.TestTimeLimitingCollector.testTimeoutMultiThreaded(TestTimeLimitingCollector.java:266) Build Log (for compile errors): [...truncated 5317 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3078) Add generics to DocumentsWriterDeleteQueue.Node
Add generics to DocumentsWriterDeleteQueue.Node --- Key: LUCENE-3078 URL: https://issues.apache.org/jira/browse/LUCENE-3078 Project: Lucene - Java Issue Type: Task Reporter: Uwe Schindler DocumentsWriterDeleteQueue.Note should be generic as the subclasses hold different types of items. This generification is a little bit tricks, but the generics policeman can't wait to fix this *g*. -- This message is automatically generated by JIRA. 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: Improvements to the maven build
On May 4, 2011, at 7:14 PM, Ryan McKinley wrote: > As a rule, everything should go through JIRA on its way to svn -- this > is important so that we have somewhere to point for why we did things. > Even small things. Even "small" things?! It would be a royal pain in the ass to submit an issue for every last stupid typo, reformat, and minor thing. I would also hope that if a committer authored a chunk of code that he believed, after the first iteration has already been committed, could use some "minor" tweak that lets say improves the clarity of the logic or has a better private method name, that he could just go ahead and commit the minor tweak. I hope that you guys are not burdened by JIRA for such things! ~ David - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Improvements to the maven build
On May 4, 2011, at 6:43 PM, Steven A Rowe wrote: >> >> 6. The ant solr build puts all its final artifacts into the solr/dist >> directory, the maven build does not--it leaves all of them in their build >> directory. Not a big deal but maybe there's a way to have the output file >> go someplace else? Not sure. > > I meant to keep the Maven build output location the same as the Ant build > output location. I think the Solr modules' POMs can and should be changed to > eliminate this difference. I'm a little unclear on what you mean by "I think the Solr modules' POMs can and should be changed to eliminate this difference". Do you mean we should ensure there is no difference in build output locations between the maven and ant builds? If so then how do we deal with the fact that the ant builds wants to put the solrj jar into a compilation output directory? You committed my patch that puts the compilation output directory one more level in under "classes" -- this creates a difference between the builds. ~ David - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-docvalues-branch - Build # 1071 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-docvalues-branch/1071/ 1 tests failed. REGRESSION: org.apache.lucene.store.TestLockFactory.testStressLocksNativeFSLockFactory Error Message: IndexWriter hit unexpected exceptions Stack Trace: junit.framework.AssertionFailedError: IndexWriter hit unexpected exceptions at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1260) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1189) at org.apache.lucene.store.TestLockFactory._testStressLocks(TestLockFactory.java:164) at org.apache.lucene.store.TestLockFactory.testStressLocksNativeFSLockFactory(TestLockFactory.java:144) Build Log (for compile errors): [...truncated 4221 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2501) [contrib/uima] Make it possible to load AE descriptors both from filesystem and classpath
[contrib/uima] Make it possible to load AE descriptors both from filesystem and classpath - Key: SOLR-2501 URL: https://issues.apache.org/jira/browse/SOLR-2501 Project: Solr Issue Type: Improvement Reporter: Tommaso Teofili AE can be loaded only from jars (via classpath) while it'd be good to make it possible to load an AnalysisEngine (specified in the analysisEngine element of UIMA configuration inside solrconfig.xml) from filesystem -- This message is automatically generated by JIRA. 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] Solr-trunk - Build # 1497 - Failure
Build: https://builds.apache.org/hudson/job/Solr-trunk/1497/ All tests passed Build Log (for compile errors): [...truncated 21401 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3077) DWPT doesn't see changes to DW#infoStream
[ https://issues.apache.org/jira/browse/LUCENE-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029881#comment-13029881 ] Earwin Burrfoot commented on LUCENE-3077: - We should just make it final everywhere ... > DWPT doesn't see changes to DW#infoStream > - > > Key: LUCENE-3077 > URL: https://issues.apache.org/jira/browse/LUCENE-3077 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 4.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.0 > > > DW does not push infostream changes to DWPT since DWPT#infoStream is final > and initialized on DWPTPool initialization (at least for initial DWPT) we > should push changes to infostream to DWPT too -- This message is automatically generated by JIRA. 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-3065) NumericField should be stored in binary format in index (matching Solr's format)
[ https://issues.apache.org/jira/browse/LUCENE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029908#comment-13029908 ] Robert Muir commented on LUCENE-3065: - ahh sorry I missed that. patch looks good to me though! > NumericField should be stored in binary format in index (matching Solr's > format) > > > Key: LUCENE-3065 > URL: https://issues.apache.org/jira/browse/LUCENE-3065 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Reporter: Michael McCandless >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, > LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, > LUCENE-3065.patch, LUCENE-3065.patch > > > (Spinoff of LUCENE-3001) > Today when writing stored fields we don't record that the field was a > NumericField, and so at IndexReader time you get back an "ordinary" Field and > your number has turned into a string. See > https://issues.apache.org/jira/browse/LUCENE-1701?focusedCommentId=12721972&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12721972 > We have spare bits already in stored fields, so, we should use one to record > that the field is numeric, and then encode the numeric field in Solr's > more-compact binary format. > A nice side-effect is we fix the long standing issue that you don't get a > NumericField back when loading your document. -- This message is automatically generated by JIRA. 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-3065) NumericField should be stored in binary format in index (matching Solr's format)
[ https://issues.apache.org/jira/browse/LUCENE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029906#comment-13029906 ] Uwe Schindler commented on LUCENE-3065: --- bq. Just to note: We also need to change the Forrest index format documentation! I already commented on that :-) [https://issues.apache.org/jira/browse/LUCENE-3065?focusedCommentId=13028718&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13028718] > NumericField should be stored in binary format in index (matching Solr's > format) > > > Key: LUCENE-3065 > URL: https://issues.apache.org/jira/browse/LUCENE-3065 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Reporter: Michael McCandless >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, > LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, > LUCENE-3065.patch, LUCENE-3065.patch > > > (Spinoff of LUCENE-3001) > Today when writing stored fields we don't record that the field was a > NumericField, and so at IndexReader time you get back an "ordinary" Field and > your number has turned into a string. See > https://issues.apache.org/jira/browse/LUCENE-1701?focusedCommentId=12721972&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12721972 > We have spare bits already in stored fields, so, we should use one to record > that the field is numeric, and then encode the numeric field in Solr's > more-compact binary format. > A nice side-effect is we fix the long standing issue that you don't get a > NumericField back when loading your document. -- This message is automatically generated by JIRA. 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-3065) NumericField should be stored in binary format in index (matching Solr's format)
[
https://issues.apache.org/jira/browse/LUCENE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029903#comment-13029903
]
Robert Muir commented on LUCENE-3065:
-
{quote}
I just add this TODO here:
Don't forget to add a new 3.1 index format to TestBackwardsCompatibility!
{quote}
Can we also update the description of the bits in fileformats.html?
> NumericField should be stored in binary format in index (matching Solr's
> format)
>
>
> Key: LUCENE-3065
> URL: https://issues.apache.org/jira/browse/LUCENE-3065
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
>Reporter: Michael McCandless
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch,
> LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch,
> LUCENE-3065.patch, LUCENE-3065.patch
>
>
> (Spinoff of LUCENE-3001)
> Today when writing stored fields we don't record that the field was a
> NumericField, and so at IndexReader time you get back an "ordinary" Field and
> your number has turned into a string. See
> https://issues.apache.org/jira/browse/LUCENE-1701?focusedCommentId=12721972&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12721972
> We have spare bits already in stored fields, so, we should use one to record
> that the field is numeric, and then encode the numeric field in Solr's
> more-compact binary format.
> A nice side-effect is we fix the long standing issue that you don't get a
> NumericField back when loading your document.
--
This message is automatically generated by JIRA.
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] [Resolved] (LUCENE-3076) add -Dtests.codecprovider
[
https://issues.apache.org/jira/browse/LUCENE-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-3076.
-
Resolution: Fixed
Committed revision 1100175.
> add -Dtests.codecprovider
> -
>
> Key: LUCENE-3076
> URL: https://issues.apache.org/jira/browse/LUCENE-3076
> Project: Lucene - Java
> Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 4.0
>
> Attachments: LUCENE-3076.patch
>
>
> Currently to test a codec (or set of codecs) you have to add them to lucene's
> core and edit a couple of arrays here and there...
> It would be nice if when using the test-framework you could instead specify a
> codecprovider by classname (possibly containing your own set of huper-duper
> codecs).
> For example I made the following little codecprovider in contrib:
> {noformat}
> public class AppendingCodecProvider extends CodecProvider {
> public AppendingCodecProvider() {
> register(new AppendingCodec());
> register(new SimpleTextCodec());
> }
> }
> {noformat}
> Then, I'm able to run tests with 'ant -lib
> build/contrib/misc/lucene-misc-4.0-SNAPSHOT.jar test-core
> -Dtests.codecprovider=org.apache.lucene.index.codecs.appending.AppendingCodecProvider',
> and it always picks from my set of codecs (in this case Appending and
> SimpleText), and I can set -Dtests.codec=Appending if i want to set just one.
--
This message is automatically generated by JIRA.
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-3077) DWPT doesn't see changes to DW#infoStream
[ https://issues.apache.org/jira/browse/LUCENE-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029896#comment-13029896 ] Simon Willnauer commented on LUCENE-3077: - I will commit this soon if nobody objects > DWPT doesn't see changes to DW#infoStream > - > > Key: LUCENE-3077 > URL: https://issues.apache.org/jira/browse/LUCENE-3077 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 4.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3077.patch > > > DW does not push infostream changes to DWPT since DWPT#infoStream is final > and initialized on DWPTPool initialization (at least for initial DWPT) we > should push changes to infostream to DWPT too -- This message is automatically generated by JIRA. 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-3065) NumericField should be stored in binary format in index (matching Solr's format)
[ https://issues.apache.org/jira/browse/LUCENE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029873#comment-13029873 ] Michael McCandless commented on LUCENE-3065: Looks great Uwe! Awesome to finally get NumericField back at search time... > NumericField should be stored in binary format in index (matching Solr's > format) > > > Key: LUCENE-3065 > URL: https://issues.apache.org/jira/browse/LUCENE-3065 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Reporter: Michael McCandless >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, > LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, > LUCENE-3065.patch, LUCENE-3065.patch > > > (Spinoff of LUCENE-3001) > Today when writing stored fields we don't record that the field was a > NumericField, and so at IndexReader time you get back an "ordinary" Field and > your number has turned into a string. See > https://issues.apache.org/jira/browse/LUCENE-1701?focusedCommentId=12721972&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12721972 > We have spare bits already in stored fields, so, we should use one to record > that the field is numeric, and then encode the numeric field in Solr's > more-compact binary format. > A nice side-effect is we fix the long standing issue that you don't get a > NumericField back when loading your document. -- This message is automatically generated by JIRA. 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-3077) DWPT doesn't see changes to DW#infoStream
[ https://issues.apache.org/jira/browse/LUCENE-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029884#comment-13029884 ] Simon Willnauer commented on LUCENE-3077: - bq. I think you should be able to set it while you are useing IW. its really just like enable debugging though. No need to final or even add to IWC I think that said I think changing to a logging framework would be good but hardly feasible > DWPT doesn't see changes to DW#infoStream > - > > Key: LUCENE-3077 > URL: https://issues.apache.org/jira/browse/LUCENE-3077 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 4.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3077.patch > > > DW does not push infostream changes to DWPT since DWPT#infoStream is final > and initialized on DWPTPool initialization (at least for initial DWPT) we > should push changes to infostream to DWPT too -- This message is automatically generated by JIRA. 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-3077) DWPT doesn't see changes to DW#infoStream
[ https://issues.apache.org/jira/browse/LUCENE-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029883#comment-13029883 ] Simon Willnauer commented on LUCENE-3077: - bq. We should just make it final everywhere ... I think you should be able to set it while you are useing IW. its really just like enable debugging though. No need to final or even add to IWC I think > DWPT doesn't see changes to DW#infoStream > - > > Key: LUCENE-3077 > URL: https://issues.apache.org/jira/browse/LUCENE-3077 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 4.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3077.patch > > > DW does not push infostream changes to DWPT since DWPT#infoStream is final > and initialized on DWPTPool initialization (at least for initial DWPT) we > should push changes to infostream to DWPT too -- This message is automatically generated by JIRA. 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-3077) DWPT doesn't see changes to DW#infoStream
[ https://issues.apache.org/jira/browse/LUCENE-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-3077: Attachment: LUCENE-3077.patch simple patch > DWPT doesn't see changes to DW#infoStream > - > > Key: LUCENE-3077 > URL: https://issues.apache.org/jira/browse/LUCENE-3077 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 4.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3077.patch > > > DW does not push infostream changes to DWPT since DWPT#infoStream is final > and initialized on DWPTPool initialization (at least for initial DWPT) we > should push changes to infostream to DWPT too -- This message is automatically generated by JIRA. 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] (LUCENE-3077) DWPT doesn't see changes to DW#infoStream
DWPT doesn't see changes to DW#infoStream - Key: LUCENE-3077 URL: https://issues.apache.org/jira/browse/LUCENE-3077 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: 4.0 Reporter: Simon Willnauer Priority: Minor Fix For: 4.0 DW does not push infostream changes to DWPT since DWPT#infoStream is final and initialized on DWPTPool initialization (at least for initial DWPT) we should push changes to infostream to DWPT too -- This message is automatically generated by JIRA. 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-3071) PathHierarchyTokenizer adaptation for urls: splits reversed
[
https://issues.apache.org/jira/browse/LUCENE-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029840#comment-13029840
]
Simon Willnauer commented on LUCENE-3071:
-
bq. I had some trouble merging from trunk to 3.x, and needed to just copy a few
files – i hope that does not muck stuff up.
that change didn't seem to be hard to merge what did you do instead or merging?
Maybe next time you should ask how to do it before copying stuff from trunk to
branch?
we also have a "how to merge" wiki here
http://wiki.apache.org/lucene-java/SvnMerge
I merged the missing file in and committed I will close once hudson is building
correctly.
> PathHierarchyTokenizer adaptation for urls: splits reversed
> ---
>
> Key: LUCENE-3071
> URL: https://issues.apache.org/jira/browse/LUCENE-3071
> Project: Lucene - Java
> Issue Type: New Feature
> Components: contrib/analyzers
>Reporter: Olivier Favre
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3071.patch, LUCENE-3071.patch, LUCENE-3071.patch,
> LUCENE-3071.patch, ant.log.tar.bz2
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {{PathHierarchyTokenizer}} should be usable to split urls the a "reversed"
> way (useful for faceted search against urls):
> {{www.site.com}} -> {{www.site.com, site.com, com}}
> Moreover, it should be able to skip a given number of first (or last, if
> reversed) tokens:
> {{/usr/share/doc/somesoftware/INTERESTING/PART}}
> Should give with 4 tokens skipped:
> {{INTERESTING}}
> {{INTERESTING/PART}}
--
This message is automatically generated by JIRA.
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 # 7777 - Still Failing
merged missing file in and committed revision 1100131. simon On Fri, May 6, 2011 at 10:40 AM, Simon Willnauer wrote: > seems like there is a file missing - I am working on it > > simon > > On Fri, May 6, 2011 at 9:40 AM, Apache Jenkins Server > wrote: >> Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x// >> >> No tests ran. >> >> Build Log (for compile errors): >> [...truncated 472 lines...] >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyTokenizer( new StringReader(path) ); >> [javac] ^ >> [javac] >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:50: >> cannot find symbol >> [javac] symbol : class ReversePathHierarchyTokenizer >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyTokenizer( new StringReader(path) ); >> [javac] ^ >> [javac] >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:61: >> cannot find symbol >> [javac] symbol : class ReversePathHierarchyTokenizer >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyTokenizer( new StringReader(path) ); >> [javac] ^ >> [javac] >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:61: >> cannot find symbol >> [javac] symbol : class ReversePathHierarchyTokenizer >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyTokenizer( new StringReader(path) ); >> [javac] ^ >> [javac] >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:72: >> cannot find symbol >> [javac] symbol : class ReversePathHierarchyTokenizer >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyTokenizer( new StringReader(path) ); >> [javac] ^ >> [javac] >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:72: >> cannot find symbol >> [javac] symbol : class ReversePathHierarchyTokenizer >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyTokenizer( new StringReader(path) ); >> [javac] ^ >> [javac] >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:83: >> cannot find symbol >> [javac] symbol : class ReversePathHierarchyTokenizer >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyTokenizer( new StringReader(path) ); >> [javac] ^ >> [javac] >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:83: >> cannot find symbol >> [javac] symbol : class ReversePathHierarchyTokenizer >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyTokenizer( new StringReader(path) ); >> [javac] ^ >> [javac] >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:94: >> cannot find symbol >> [javac] symbol : class ReversePathHierarchyTokenizer >> [javac] location: class >> org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer >> [javac] ReversePathHierarchyTokenizer t = new >> ReversePathHierarchyT
[jira] [Reopened] (LUCENE-3071) PathHierarchyTokenizer adaptation for urls: splits reversed
[
https://issues.apache.org/jira/browse/LUCENE-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer reopened LUCENE-3071:
-
we got failures due to a missing file on 3.x - reopen
> PathHierarchyTokenizer adaptation for urls: splits reversed
> ---
>
> Key: LUCENE-3071
> URL: https://issues.apache.org/jira/browse/LUCENE-3071
> Project: Lucene - Java
> Issue Type: New Feature
> Components: contrib/analyzers
>Reporter: Olivier Favre
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3071.patch, LUCENE-3071.patch, LUCENE-3071.patch,
> LUCENE-3071.patch, ant.log.tar.bz2
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {{PathHierarchyTokenizer}} should be usable to split urls the a "reversed"
> way (useful for faceted search against urls):
> {{www.site.com}} -> {{www.site.com, site.com, com}}
> Moreover, it should be able to skip a given number of first (or last, if
> reversed) tokens:
> {{/usr/share/doc/somesoftware/INTERESTING/PART}}
> Should give with 4 tokens skipped:
> {{INTERESTING}}
> {{INTERESTING/PART}}
--
This message is automatically generated by JIRA.
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 # 7777 - Still Failing
seems like there is a file missing - I am working on it simon On Fri, May 6, 2011 at 9:40 AM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x// > > No tests ran. > > Build Log (for compile errors): > [...truncated 472 lines...] > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path) ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:50: > cannot find symbol > [javac] symbol : class ReversePathHierarchyTokenizer > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path) ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:61: > cannot find symbol > [javac] symbol : class ReversePathHierarchyTokenizer > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path) ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:61: > cannot find symbol > [javac] symbol : class ReversePathHierarchyTokenizer > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path) ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:72: > cannot find symbol > [javac] symbol : class ReversePathHierarchyTokenizer > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path) ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:72: > cannot find symbol > [javac] symbol : class ReversePathHierarchyTokenizer > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path) ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:83: > cannot find symbol > [javac] symbol : class ReversePathHierarchyTokenizer > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path) ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:83: > cannot find symbol > [javac] symbol : class ReversePathHierarchyTokenizer > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path) ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:94: > cannot find symbol > [javac] symbol : class ReversePathHierarchyTokenizer > [javac] location: class > org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer > [javac] ReversePathHierarchyTokenizer t = new > ReversePathHierarchyTokenizer( new StringReader(path), 1 ); > [javac] ^ > [javac] > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/anal
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 7777 - Still Failing
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x// No tests ran. Build Log (for compile errors): [...truncated 472 lines...] [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:50: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:61: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:61: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:72: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:72: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:83: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:83: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:94: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path), 1 ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:94: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReverseP
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 7776 - Still Failing
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7776/ No tests ran. Build Log (for compile errors): [...truncated 472 lines...] [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:50: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:61: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:61: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:72: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:72: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:83: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:83: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path) ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:94: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReversePathHierarchyTokenizer t = new ReversePathHierarchyTokenizer( new StringReader(path), 1 ); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/contrib/analyzers/common/src/test/org/apache/lucene/analysis/path/TestReversePathHierarchyTokenizer.java:94: cannot find symbol [javac] symbol : class ReversePathHierarchyTokenizer [javac] location: class org.apache.lucene.analysis.path.TestReversePathHierarchyTokenizer [javac] ReverseP
[jira] [Commented] (SOLR-2497) Move Solr to new NumericField stored field impl of LUCENE-3065
[ https://issues.apache.org/jira/browse/SOLR-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029797#comment-13029797 ] Uwe Schindler commented on SOLR-2497: - I think this is now ready to commit. > Move Solr to new NumericField stored field impl of LUCENE-3065 > -- > > Key: SOLR-2497 > URL: https://issues.apache.org/jira/browse/SOLR-2497 > Project: Solr > Issue Type: Improvement >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.2, 4.0 > > Attachments: SOLR-2497.patch, SOLR-2497.patch, SOLR-2497.patch, > SOLR-2497.patch > > > This implements the changes to NumericField (LUCENE-3065) in Solr. TrieField > & Co would use NumericField for indexing and reading stored fields. To enable > this some missing changes in Solr's internals (Field -> Fieldable) need to be > done. Also some backwards compatible stored fields parsing is needed to read > pre-3.2 indexes without reindexing (as the format changed a little bit and > Document.getFieldable returns NumericField instances now). -- This message is automatically generated by JIRA. 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-3065) NumericField should be stored in binary format in index (matching Solr's format)
[ https://issues.apache.org/jira/browse/LUCENE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3065: -- Attachment: LUCENE-3065.patch New patch with the changes proposed before (no more instanceof chains). I think this is now ready to commit. > NumericField should be stored in binary format in index (matching Solr's > format) > > > Key: LUCENE-3065 > URL: https://issues.apache.org/jira/browse/LUCENE-3065 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Reporter: Michael McCandless >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, > LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, LUCENE-3065.patch, > LUCENE-3065.patch, LUCENE-3065.patch > > > (Spinoff of LUCENE-3001) > Today when writing stored fields we don't record that the field was a > NumericField, and so at IndexReader time you get back an "ordinary" Field and > your number has turned into a string. See > https://issues.apache.org/jira/browse/LUCENE-1701?focusedCommentId=12721972&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12721972 > We have spare bits already in stored fields, so, we should use one to record > that the field is numeric, and then encode the numeric field in Solr's > more-compact binary format. > A nice side-effect is we fix the long standing issue that you don't get a > NumericField back when loading your document. -- This message is automatically generated by JIRA. 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
