date:20110817

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 10195 - Still Failing

2011-08-17 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/10195/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration

Error Message:
expected:2 but was:3

Stack Trace:
junit.framework.AssertionFailedError: expected:2 but was:3
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1526)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1428)
at 
org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration(CloudStateUpdateTest.java:198)




Build Log (for compile errors):
[...truncated 7956 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2708) Allow customizable bean mapping for QueryResponse.getBeans(..)

2011-08-17 Thread Chris Male (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Male updated SOLR-2708:
-

Attachment: SOLR-2708.patch

Another patch doing more cleanup, particularly in the tests.

I'm starting to get an idea of whats needed here.

 Allow customizable bean mapping for QueryResponse.getBeans(..)
 --

 Key: SOLR-2708
 URL: https://issues.apache.org/jira/browse/SOLR-2708
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 1.4, 3.1
Reporter: Bozhidar Bozhanov
 Attachments: SOLR-2708.patch, SOLR-2708.patch


 The mechanism for getting beans is rather limited - only classes 
 @Field-annotated fields.
 Imaging the following subprojects:
 - common
 - search
 And you want to reuse a class from common as a result from a solr search. You 
 should either duplicate the structure or make common depend on solrj. Neither 
 are desirable.
 So, my suggestion:
 - introduce a pluggable mechanism for bean resolution. Currently it is 
 impossible - it uses private methods and private inner classes. (This will be 
 useful for custom conversions, because the existing one fails in some cases 
 where BeanUtils.copyProperties works.)
 - allow externalized (xml) configuration
 - allow detecting all fields, annotated or not (off by default)

--
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-1768) NumericRange support for new query parser

2011-08-17 Thread Uwe Schindler (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086181#comment-13086181
 ] 

Uwe Schindler commented on LUCENE-1768:
---

I have no problems with the patch, too. We have unfortunately no real backwards 
tests for contribs, but I see no major problems.

I will commit this soon and record merges from trunk, so the commits are 
related by mergeprops. What changes are still missing from trunk that will 
never be backported?

Adriano: Can you summarize all your changes in both issues into a changes.txt 
entry for both branches?

 NumericRange support for new query parser
 -

 Key: LUCENE-1768
 URL: https://issues.apache.org/jira/browse/LUCENE-1768
 Project: Lucene - Java
  Issue Type: New Feature
  Components: core/queryparser
Affects Versions: 2.9
Reporter: Uwe Schindler
Assignee: Uwe Schindler
  Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
 Fix For: 4.0

 Attachments: TestNumericQueryParser-fix.patch, 
 TestNumericQueryParser-fix.patch, TestNumericQueryParser-fix.patch, 
 TestNumericQueryParser-fix.patch, week-7.patch, week-8.patch, week1.patch, 
 week11-13_for_lucene_3x.patch, week2.patch, week3.patch, week4.patch, 
 week5-6.patch


 It would be good to specify some type of schema for the query parser in 
 future, to automatically create NumericRangeQuery for different numeric 
 types? It would then be possible to index a numeric value 
 (double,float,long,int) using NumericField and then the query parser knows, 
 which type of field this is and so it correctly creates a NumericRangeQuery 
 for strings like [1.567..*] or (1.787..19.5].
 There is currently no way to extract if a field is numeric from the index, so 
 the user will have to configure the FieldConfig objects in the ConfigHandler. 
 But if this is done, it will not be that difficult to implement the rest.
 The only difference between the current handling of RangeQuery is then the 
 instantiation of the correct Query type and conversion of the entered numeric 
 values (simple Number.valueOf(...) cast of the user entered numbers). 
 Evenerything else is identical, NumericRangeQuery also supports the MTQ 
 rewrite modes (as it is a MTQ).
 Another thing is a change in Date semantics. There are some strange flags in 
 the current parser that tells it how to handle dates.

--
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-3305) Kuromoji code donation - a new Japanese morphological analyzer

2011-08-17 Thread Simon Willnauer (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086186#comment-13086186
]

Simon Willnauer commented on LUCENE-3305:
-

FYI - I created an issue on legal to categorize the IPADIC license LEGAL-97

Kuromoji code donation - a new Japanese morphological analyzer
--

Key: LUCENE-3305
URL: https://issues.apache.org/jira/browse/LUCENE-3305
Project: Lucene - Java
Issue Type: New Feature
Components: modules/analysis
Reporter: Christian Moen
Assignee: Simon Willnauer
Attachments: Kuromoji short overview .pdf, ip-clearance-Kuromoji.xml,
kuromoji-0.7.6-asf.tar.gz, kuromoji-0.7.6.tar.gz,
kuromoji-solr-0.5.3-asf.tar.gz, kuromoji-solr-0.5.3.tar.gz

Atilika Inc. (アティリカ株式会社) would like to donate the Kuromoji Japanese
morphological analyzer to the Apache Software Foundation in the hope that it
will be useful to Lucene and Solr users in Japan and elsewhere.
The project was started in 2010 since we couldn't find any high-quality,
actively maintained and easy-to-use Java-based Japanese morphological
analyzers, and these become many of our design goals for Kuromoji.
Kuromoji also has a segmentation mode that is particularly useful for search,
which we hope will interest Lucene and Solr users. Compound-nouns, such as
関西国際空港 (Kansai International Airport) and 日本経済新聞 (Nikkei Newspaper), are
segmented as one token with most analyzers. As a result, a search for 空港
(airport) or 新聞 (newspaper) will not give you a for in these words. Kuromoji
can segment these words into 関西 国際 空港 and 日本 経済 新聞, which is generally what
you would want for search and you'll get a hit.
We also wanted to make sure the technology has a license that makes it
compatible with other Apache Software Foundation software to maximize its
usefulness. Kuromoji has an Apache License 2.0 and all code is currently
owned by Atilika Inc. The software has been developed by my good friend and
ex-colleague Masaru Hasegawa and myself.
Kuromoji uses the so-called IPADIC for its dictionary/statistical model and
its license terms are described in NOTICE.txt.
I'll upload code distributions and their corresponding hashes and I'd very
much like to start the code grant process. I'm also happy to provide patches
to integrate Kuromoji into the codebase, if you prefer that.
Please advise on how you'd like me to proceed with this. Thank you.

--
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

more granular updateRequestProcessorChain

2011-08-17 Thread Mikhail Khludnev

Hello,

I need to implement some tricky copyField like in
http://wiki.apache.org/solr/UpdateRequestProcessor.
But I need to take the SolrInputDocument field and put it into Lucene
document myself by my own UpdateRequestProcessor. Unfortunately there is no
room to do that because the creating Lucene document and its' indexing it is
the single method:

org.apache.solr.update.processor.RunUpdateProcessor.processAdd(AddUpdateCommand)
 {
cmd.doc = DocumentBuilder.toDocument(cmd.getSolrInputDocument(),
req.getSchema());
updateHandler.addDoc(cmd);
super.processAdd(cmd);
  }

I was surprised because the Chain-of-responsibility and Command pattern are
made for such usages.

I propose to separate the current RunUpdateProcessor onto
BuildLuceneDocumentProcessor and UpdateHandlerProcessor that allow users to
inject their own routines in the main flow.
Right now I had to copy-paste RunUpdateProcessor to get my purpose.

WDYT?

-- 
Sincerely yours
Mikhail (Mike) Khludnev
Developer
Grid Dynamics
Skype: mkhludnev
mkhlud...@griddynamics.com

Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 10193 - Still Failing

2011-08-17 Thread Martijn v Groningen

I'll investigate this test failure.

On 17 August 2011 04:31, Robert Muir rcm...@gmail.com wrote:

 This test fails if NUM_ORD  2, which is the case when a
 -Dtests.multiplier  1 is used.

 I temporarily wired NUM_ORD to 2, and reopened/put a comment on
 https://issues.apache.org/jira/browse/LUCENE-3354

 On Tue, Aug 16, 2011 at 10:01 PM, Apache Jenkins Server
 jenk...@builds.apache.org wrote:
  Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/10193/
 
  1 tests failed.
  FAILED:  org.apache.lucene.search.TestFieldCache.test
 
  Error Message:
  Expected value gm镩Ǫᥨ¢
 뢕J[㍤˩൘Σ͆eﳖꤧ忌㐓ӳs䚮ǟ݁ґwЩ焃̣(uبޘ雡{׶ڍ躷廛(JҨ鍧遼ﳖ砏ԙ羀α㱧햞疎ٛ̦ﳺ̕n誢̷º;Ԟँ̟ۛހ㒯Ԁ협׸E۶络kʺ먨ˋ켿؇Ty洔Ҕ⮄鈷֤䆡掌槛ŗᏓ盜鎴ģP繯؉雏唪
 for doc 0 and ord 0, but was ڬﮎ՚ᆩʛ웍ে瞊ؘسȣ澏掤ŻⓉªW嵆⁊ӌ颽ɧɉīÓ59݂d뫇זόѭ
 筋踠⫔戇呾平Խ0ҭd$꒼
 
  Stack Trace:
  junit.framework.AssertionFailedError: Expected value gm镩Ǫᥨ¢
 뢕J[㍤˩൘Σ͆eﳖꤧ忌㐓ӳs䚮ǟ݁ґwЩ焃̣(uبޘ雡{׶ڍ躷廛(JҨ鍧遼ﳖ砏ԙ羀α㱧햞疎ٛ̦ﳺ̕n誢̷º;Ԟँ̟ۛހ㒯Ԁ협׸E۶络kʺ먨ˋ켿؇Ty洔Ҕ⮄鈷֤䆡掌槛ŗᏓ盜鎴ģP繯؉雏唪
 for doc 0 and ord 0, but was ڬﮎ՚ᆩʛ웍ে瞊ؘسȣ澏掤ŻⓉªW嵆⁊ӌ颽ɧɉīÓ59݂d뫇זόѭ
  筋踠⫔戇呾平Խ0ҭd$꒼
 at
 org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1526)
 at
 org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1428)
  筋踠⫔戇呾平Խ0ҭd$꒼
 at
 org.apache.lucene.search.TestFieldCache.test(TestFieldCache.java:246)
 
 
 
 
  Build Log (for compile errors):
  [...truncated 1217 lines...]
 
 



 --
 lucidimagination.com




-- 
Met vriendelijke groet,

Martijn van Groningen

[jira] [Commented] (LUCENE-3354) Extend FieldCache architecture to multiple Values

2011-08-17 Thread Martijn van Groningen (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086197#comment-13086197
 ] 

Martijn van Groningen commented on LUCENE-3354:
---

I committed a fix. Test pass now on my local box with -Dtests.multiplier=3.
If build is successful on Jenkins we can close this issue.

 Extend FieldCache architecture to multiple Values
 -

 Key: LUCENE-3354
 URL: https://issues.apache.org/jira/browse/LUCENE-3354
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Bill Bell
 Fix For: 4.0

 Attachments: LUCENE-3354.patch, LUCENE-3354.patch


 I would consider this a bug. It appears lots of people are working around 
 this limitation, 
 why don't we just change the underlying data structures to natively support 
 multiValued fields in the FieldCache architecture?
 Then functions() will work properly, and we can do things like easily 
 geodist() on a multiValued field.
 Thoughts?

--
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-2700) transaction logging

2011-08-17 Thread Noble Paul (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086207#comment-13086207
 ] 

Noble Paul commented on SOLR-2700:
--

Realtime get can be a separate issue altogether. These are two distinct features

 transaction logging
 ---

 Key: SOLR-2700
 URL: https://issues.apache.org/jira/browse/SOLR-2700
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch


 A transaction log is needed for durability of updates, for a more performant 
 realtime-get, and for replaying updates to recovering peers.

--
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 # 1601 - Failure

2011-08-17 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Solr-trunk/1601/

1 tests failed.
REGRESSION:  org.apache.solr.update.AutoCommitTest.testSoftAndHardCommitMaxTime

Error Message:
expected:2 but was:3

Stack Trace:
junit.framework.AssertionFailedError: expected:2 but was:3
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1526)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1428)
at 
org.apache.solr.update.AutoCommitTest.__CLR2_6_396rfj913je(AutoCommitTest.java:438)
at 
org.apache.solr.update.AutoCommitTest.testSoftAndHardCommitMaxTime(AutoCommitTest.java:366)




Build Log (for compile errors):
[...truncated 27375 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

85 matches

Mail list logo