Re: [VOTE] Release PyLucene 3.3.0
Hi Mike, On Sun, 3 Jul 2011, Michael McCandless wrote: Re-send, this time to pylucene-dev: Everything looks good -- I was able to compile, run all tests successfully, and run my usual smoke test (indexing optimizing searching on first 100K wikipedia docs), but... I then tried to enable the grouping module (lucene/contrib/grouping), by adding a GROUPING_JAR matching all the other contrib jars, and running make. This then hit various compilation errors -- is anyone able to enable the grouping module and compile successfully? What kind of errors ? So I added the grouping module to the PyLucene branch_3x build and it just built (tm). I even committed the change to the build (rev 1142455) but I didn't check that the grouping module was functional in PyLucene as I didn't port any unit tests or even know much about it. Andi.. Mike McCandless http://blog.mikemccandless.com On Sun, Jul 3, 2011 at 10:14 AM, Michael McCandless luc...@mikemccandless.com wrote: Everything looks good -- I was able to compile, run all tests successfully, and run my usual smoke test (indexing optimizing searching on first 100K wikipedia docs), but... I then tried to enable the grouping module (lucene/contrib/grouping), by adding a GROUPING_JAR matching all the other contrib jars, and running make. This then hit various compilation errors -- is anyone able to enable the grouping module and compile successfully? Mike McCandless http://blog.mikemccandless.com On Fri, Jul 1, 2011 at 8:24 AM, Andi Vajda va...@apache.org wrote: The PyLucene 3.3.0-1 release closely tracking the recent release of Lucene Java 3.3 is ready. A release candidate is available from: http://people.apache.org/~vajda/staging_area/ A list of changes in this release can be seen at: http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_3_3/CHANGES PyLucene 3.3.0 is built with JCC 2.9 included in these release artifacts. A list of Lucene Java changes can be seen at: http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_3_3/lucene/CHANGES.txt Please vote to release these artifacts as PyLucene 3.3.0-1. Thanks ! Andi.. ps: the KEYS file for PyLucene release signing is at: http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS http://people.apache.org/~vajda/staging_area/KEYS pps: here is my +1
Re: [VOTE] Release PyLucene 3.3.0
Am 03.07.2011 18:17, schrieb Andi Vajda: What kind of errors ? So I added the grouping module to the PyLucene branch_3x build and it just built (tm). I even committed the change to the build (rev 1142455) but I didn't check that the grouping module was functional in PyLucene as I didn't port any unit tests or even know much about it. I'm getting an error on my box, too. In file included from build/_lucene/__wrap01__.cpp:39469:0: build/_lucene/org/apache/lucene/search/grouping/AbstractSecondPassGroupingCollector$SearchGroupDocs.h:55:83: error: ‘AbstractSecondPassGroupingCollector’ in namespace ‘org::apache::lucene::search::grouping’ does not name a type build/_lucene/org/apache/lucene/search/grouping/AbstractSecondPassGroupingCollector$SearchGroupDocs.h:55:160: error: ISO C++ forbids declaration of ‘parameter’ with no type build/_lucene/__wrap01__.cpp:39503:132: error: ‘AbstractSecondPassGroupingCollector’ in namespace ‘org::apache::lucene::search::grouping’ does not name a type build/_lucene/__wrap01__.cpp:39503:211: error: ISO C++ forbids declaration of ‘a0’ with no type build/_lucene/__wrap01__.cpp: In constructor ‘org::apache::lucene::search::grouping::AbstractSecondPassGroupingCollector$SearchGroupDocs::AbstractSecondPassGroupingCollector$SearchGroupDocs(const int, const java::lang::Object, const org::apache::lucene::search::TopDocsCollector)’: build/_lucene/__wrap01__.cpp:39503:394: error: request for member ‘this$’ in ‘a0’, which is of non-class type ‘const int’ build/_lucene/__wrap01__.cpp: In function ‘int org::apache::lucene::search::grouping::t_AbstractSecondPassGroupingCollector$SearchGroupDocs_init_(org::apache::lucene::search::grouping::t_AbstractSecondPassGroupingCollector$SearchGroupDocs*, PyObject*, PyObject*)’: build/_lucene/__wrap01__.cpp:39608:25: error: ‘AbstractSecondPassGroupingCollector’ is not a member of ‘org::apache::lucene::search::grouping’ build/_lucene/__wrap01__.cpp:39608:102: error: expected ‘;’ before ‘a0’ build/_lucene/__wrap01__.cpp:39615:30: error: ‘org::apache::lucene::search::grouping::AbstractSecondPassGroupingCollector’ has not been declared build/_lucene/__wrap01__.cpp:39615:30: error: ‘a0’ was not declared in this scope build/_lucene/__wrap01__.cpp:39615:30: error: ‘org::apache::lucene::search::grouping::t_AbstractSecondPassGroupingCollector’ has not been declared error: command 'gcc' failed with exit status 1 Ubuntu 11.04 x86_64 GCC 4.5.2 Python 2.7.2 Christian
Re: [VOTE] Release PyLucene 3.3.0
On Sun, 3 Jul 2011, Christian Heimes wrote: Am 03.07.2011 18:17, schrieb Andi Vajda: What kind of errors ? So I added the grouping module to the PyLucene branch_3x build and it just built (tm). I even committed the change to the build (rev 1142455) but I didn't check that the grouping module was functional in PyLucene as I didn't port any unit tests or even know much about it. I'm getting an error on my box, too. While I don't see the error, I see that there could be something missing in that header file, AbstractSecondPassGroupingCollector$SearchGroupDocs.h. For example, TopDocsCollector is forward-declared there but AbstractSecondPassGroupingCollector is not, even though it is used. What's special about it is that it's the outer class of the class being defined here, AbstractSecondPassGroupingCollector$SearchGroupDocs. The reason I'm not seeing there error could be a difference in file inclusion order somewhere getting this missing class definition included from somewhere else. I'm about to go on vacation for two weeks, without a computer (ok, email only) and I should investigate this upon my return. Still, that shouldn't necessarily block the PyLucene 3.3 release. I'm fine with either solution, block the release on this or fix that for 3.4. Either way, I can't finish the release process until I return as the vote has to run for three business days, ie, until Tuesday. I'll leave it up to the voters to decide :-) Andi.. In file included from build/_lucene/__wrap01__.cpp:39469:0: build/_lucene/org/apache/lucene/search/grouping/AbstractSecondPassGroupingCollector$SearchGroupDocs.h:55:83: error: ?AbstractSecondPassGroupingCollector? in namespace ?org::apache::lucene::search::grouping? does not name a type build/_lucene/org/apache/lucene/search/grouping/AbstractSecondPassGroupingCollector$SearchGroupDocs.h:55:160: error: ISO C++ forbids declaration of ?parameter? with no type build/_lucene/__wrap01__.cpp:39503:132: error: ?AbstractSecondPassGroupingCollector? in namespace ?org::apache::lucene::search::grouping? does not name a type build/_lucene/__wrap01__.cpp:39503:211: error: ISO C++ forbids declaration of ?a0? with no type build/_lucene/__wrap01__.cpp: In constructor ?org::apache::lucene::search::grouping::AbstractSecondPassGroupingCollector$SearchGroupDocs::AbstractSecondPassGroupingCollector$SearchGroupDocs(const int, const java::lang::Object, const org::apache::lucene::search::TopDocsCollector)?: build/_lucene/__wrap01__.cpp:39503:394: error: request for member ?this$? in ?a0?, which is of non-class type ?const int? build/_lucene/__wrap01__.cpp: In function ?int org::apache::lucene::search::grouping::t_AbstractSecondPassGroupingCollector$SearchGroupDocs_init_(org::apache::lucene::search::grouping::t_AbstractSecondPassGroupingCollector$SearchGroupDocs*, PyObject*, PyObject*)?: build/_lucene/__wrap01__.cpp:39608:25: error: ?AbstractSecondPassGroupingCollector? is not a member of ?org::apache::lucene::search::grouping? build/_lucene/__wrap01__.cpp:39608:102: error: expected ?;? before ?a0? build/_lucene/__wrap01__.cpp:39615:30: error: ?org::apache::lucene::search::grouping::AbstractSecondPassGroupingCollector? has not been declared build/_lucene/__wrap01__.cpp:39615:30: error: ?a0? was not declared in this scope build/_lucene/__wrap01__.cpp:39615:30: error: ?org::apache::lucene::search::grouping::t_AbstractSecondPassGroupingCollector? has not been declared error: command 'gcc' failed with exit status 1 Ubuntu 11.04 x86_64 GCC 4.5.2 Python 2.7.2 Christian
[jira] [Commented] (LUCENE-3268) TestScoredDocIDsUtils.testWithDeletions test failure
[ https://issues.apache.org/jira/browse/LUCENE-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059165#comment-13059165 ] Shai Erera commented on LUCENE-3268: The test fails consistently with this seed -Dtests.seed=2719714750176374101:2498146487036328796 on trunk. I added prints to the test for when it marks a document for deletion (it adds a term) and then traversing this term's DocsEnum. I see that the lists are off by 1 (i.e instead of 0, 3, 6, 9 ... it is 0, 2, 5, 8). So I don't think the failure is related to the facets code at all. I've noticed the following: # If I disable RandomIW, it passes # If I disable RandomIW.addDocument call to maybeCommit, it passes too. # Disabling maybeCommit.switchDoDocValues has no effect. It's the call to w.commit() which causes the IDs to offset by 1. Since RIW.flushAt is set to 51 (w/ the above seed), you can reduce the number of docs to index to 53 and the bug will be exposed (it didn't reproduce w/ N_DOCS=52). I'll try to isolate this bug to a standalone testcase and then run on 3x too. TestScoredDocIDsUtils.testWithDeletions test failure Key: LUCENE-3268 URL: https://issues.apache.org/jira/browse/LUCENE-3268 Project: Lucene - Java Issue Type: Bug Components: modules/facet Reporter: Robert Muir Fix For: 3.4, 4.0 ant test -Dtestcase=TestScoredDocIDsUtils -Dtestmethod=testWithDeletions -Dtests.seed=-2216133137948616963:2693740419732273624 -Dtests.multiplier=5 In general, on both 3.x and trunk, if you run this test with -Dtests.iter=100 it tends to fail 2% of the time. -- 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-3268) TestScoredDocIDsUtils.testWithDeletions test failure
[ https://issues.apache.org/jira/browse/LUCENE-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3268. Resolution: Fixed Assignee: Shai Erera Ok -- reproduced consistently with -Dtests.seed=2719714750176374101:2498146487036328796. Issue was that test must use LogMergePolicy and not any out-of-order merges. Committed revision 1142385 (3x). Committed revision 1142386 (trunk). TestScoredDocIDsUtils.testWithDeletions test failure Key: LUCENE-3268 URL: https://issues.apache.org/jira/browse/LUCENE-3268 Project: Lucene - Java Issue Type: Bug Components: modules/facet Reporter: Robert Muir Assignee: Shai Erera Fix For: 3.4, 4.0 ant test -Dtestcase=TestScoredDocIDsUtils -Dtestmethod=testWithDeletions -Dtests.seed=-2216133137948616963:2693740419732273624 -Dtests.multiplier=5 In general, on both 3.x and trunk, if you run this test with -Dtests.iter=100 it tends to fail 2% of the time. -- 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-1344) Make the Lucene jar an OSGi bundle
[ https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059196#comment-13059196 ] Philipp Nanz commented on LUCENE-1344: -- Can someone explain this to me: This issue is marked as resolved in 3.3, it's even listed in the changelog for 3.3, yet the lucene-core.jar file is clearly not OSGI-enabled... What's up with that?! Make the Lucene jar an OSGi bundle -- Key: LUCENE-1344 URL: https://issues.apache.org/jira/browse/LUCENE-1344 Project: Lucene - Java Issue Type: Improvement Components: general/build Reporter: Nicolas Lalevée Assignee: Ryan McKinley Priority: Minor Fix For: 3.3, 4.0 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch In order to use Lucene in an OSGi environment, some additional headers are needed in the manifest of the jar. As Lucene has no dependency, it is pretty straight forward and it ill be easy to maintain I think. -- 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-trunk - Build # 9281 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9281/ All tests passed Build Log (for compile errors): [...truncated 11905 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle
[ https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059213#comment-13059213 ] Luca Stancapiano commented on LUCENE-1344: -- This task resolves only the maven version of lucene. So you are forced to download the 3.3 lucene version and compile it with maven. The official release is compiled with Ant so the online binaries are not released for OSGI. Actually there is a open task to create an OSGI bundle through ant. It is under work: https://issues.apache.org/jira/browse/LUCENE-3167 Make the Lucene jar an OSGi bundle -- Key: LUCENE-1344 URL: https://issues.apache.org/jira/browse/LUCENE-1344 Project: Lucene - Java Issue Type: Improvement Components: general/build Reporter: Nicolas Lalevée Assignee: Ryan McKinley Priority: Minor Fix For: 3.3, 4.0 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch In order to use Lucene in an OSGi environment, some additional headers are needed in the manifest of the jar. As Lucene has no dependency, it is pretty straight forward and it ill be easy to maintain I think. -- 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 # 9250 - Failure
+1 Mike McCandless http://blog.mikemccandless.com On Sat, Jul 2, 2011 at 4:50 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hmm, the semantics have changed a little here. Now we do close the CFS in a finally block while this was simply omitted previously. Yet, I think we should allow empty CFS in such a situation nice its a valid CFS though. I don't see any problems with that, thoughts? simon On Sat, Jul 2, 2011 at 9:02 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9250/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull Error Message: CFS has no entries Stack Trace: java.lang.IllegalStateException: CFS has no entries at org.apache.lucene.store.CompoundFileWriter.close(CompoundFileWriter.java:139) at org.apache.lucene.store.CompoundFileDirectory.close(CompoundFileDirectory.java:181) at org.apache.lucene.store.DefaultCompoundFileDirectory.close(DefaultCompoundFileDirectory.java:58) at org.apache.lucene.index.SegmentMerger.createCompoundFile(SegmentMerger.java:139) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4252) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3863) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:37) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2715) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2710) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2706) at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3513) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2064) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2031) at org.apache.lucene.index.TestIndexWriterOnDiskFull.addDoc(TestIndexWriterOnDiskFull.java:539) at org.apache.lucene.index.TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull(TestIndexWriterOnDiskFull.java:74) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1277) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1195) Build Log (for compile errors): [...truncated 10583 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: revisit naming for grouping/join?
On Fri, Jul 1, 2011 at 10:02 AM, Robert Muir rcm...@gmail.com wrote: On Fri, Jul 1, 2011 at 8:51 AM, Michael McCandless luc...@mikemccandless.com wrote: The join module does currently depend on the grouping module, but for a silly reason: just for the TopGroups, to represent the returned hits. We could move TopGroups/GroupDocs into common (thus justifying its generic name!)? Then both join and grouping modules depend on common. Just a suggestion: maybe they belong in the lucene core? And maybe the stuff in the common module belongs in lucene core's util package? +1 If we can generalize TopDocs so that we parameterize the type of each hit, ie it could be a leaf (single doc + score (ScoreDoc) + maybe field values (FieldDoc)) or another TopDocs, then we don't need the separate TopGroups anymore. I guess I'm suggesting we try to keep our modules as flat as possible, with as little dependencies as possible. I think we really already have a 'common' module, thats the lucene core. If multiple modules end up relying upon the same functionality, especially if its something simple like an abstract class (Analyzer) or a utility thing (these mutable integers, etc), then thats a good sign it belongs in core apis. I like this approach. I think we really need to try to nuke all these dependencies between modules: its great to add them as a way to get refactoring started, but ultimately we should try to clean up: because we don't want a complex 'graph' of dependencies but instead something dead-simple. I made a total mess with the analyzers module at first, i think everything depended on it! but now we have nuked almost all dependencies on this thing, except for where it makes sense to have that concrete dependency (benchmark, demo, solr). Good! I think what would be best is a smallish but feature complete demo, ie pull together some easy-to-understand sample content and the build a small demo app around it. We could then show how to use grouping for field collapsing (and for other use cases), joining for nested docs (and for other use cases), etc. For the same reason listed above, I think we should take our contrib/demo and consolidate 'examples' across various places into this demo module. The reason is: * examples typically depend upon 'concrete' stuff, but in general core stuff should work around interfaces/abstract classes: e.g. the faceting module has an analyzers dependency only because of its examples. * examples might want to integrate modules, e.g. an example of how to integrate faceting and grouping or something like that. * examples are important: i think if the same question comes up on the user list often, we should consider adding an example. +1 I think especially now that we have very new interesting modules (facet, join, grouping), we really need corresponding examples to showcase all of this. Mike - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: revisit naming for grouping/join?
On Fri, Jul 1, 2011 at 9:28 AM, mark harwood markharw...@yahoo.co.uk wrote: I think what would be best is a smallish but feature complete demo, For the nested stuff I had a reasonable demo on LUCENE-2454 that was based around resumes - that use case has the one-to-many characteristics that lends itself to nested e.g. a person has many different qualifications and records of employment. This scenario was illustrated here: http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene I also had the book search type scenario where a book has many sections and for the purposes of efficient highlighting/summarisation these sections were treated as child docs which could be read quickly (rather than highlighting a whole book) I think both resumes and book search, and also others like the variants of a product SKU, would all make good examples for the nested docs use case. I'm not sure what the parent was in your doctor and cities example, Mike. If a doctor is in only one city then there is no point making city a child doc as the one city info can happily be combined with the doctor info into a single document with no conflict (doctors have different properties to cities). If the city is the parent with many child doctor docs that makes more sense but feels like a less likely use case e.g. find me a city with doctor x and a different doctor y Searching for a person with excellent java and prefrerably good lucene skills feels like a more real-world example. In my example the city was parent -- I raised this example to explain that index-time joining is more general than just nested docs (ie, I think we should keep the name join for this module... also because we should factor out more general search-time-only join capabilities into it). It feels like documenting some of the trade-offs behind index design choices is useful too e.g. nesting is not too great for very volatile content with constantly changing children while search-time join is more costly in RAM and 2-pass processing +1, especially once we've factored out generic joins. Mike - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3167) Make lucene/solr a OSGI bundle through Ant
[ https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059233#comment-13059233 ] Luca Stancapiano commented on LUCENE-3167: -- Lucene uses the 2.3.4 version of maven-bundle-plugin. So it is better downlaod the 1.15.0 version of bndlib instead of the last. The download url for bndlib 1.15.0 will be: http://mirrors.ibiblio.org/pub/mirrors/maven2/biz/aQute/bndlib/1.15.0/bndlib-1.15.0.jar Make lucene/solr a OSGI bundle through Ant -- Key: LUCENE-3167 URL: https://issues.apache.org/jira/browse/LUCENE-3167 Project: Lucene - Java Issue Type: New Feature Environment: bndtools Reporter: Luca Stancapiano We need to make a bundle thriugh Ant, so the binary can be published and no more need the download of the sources. Actually to get a OSGI bundle we need to use maven tools and build the sources. Here the reference for the creation of the OSGI bundle through Maven: https://issues.apache.org/jira/browse/LUCENE-1344 Bndtools could be used inside Ant -- 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-1932) add relevancy function queries
[ https://issues.apache.org/jira/browse/SOLR-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-1932: --- Attachment: SOLR-1932_totaltermfreq.patch Here's an update with one of the relevancy functions I missed: totaltermfreq. add relevancy function queries -- Key: SOLR-1932 URL: https://issues.apache.org/jira/browse/SOLR-1932 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Priority: Minor Fix For: 4.0 Attachments: SOLR-1932.patch, SOLR-1932_totaltermfreq.patch Add function queries for relevancy factors such as tf, idf, etc. -- 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-2632) Highlighting does not work for embedded boost query that boosts a dismax query
[
https://issues.apache.org/jira/browse/SOLR-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Antonio Farré Basurte updated SOLR-2632:
-
Labels: _query_ boost dismax edismax embedded highlighting hl.fl
query (was: _query_ boost dismax embedded highlighting hl.fl query)
Environment:
Linux.
Reproduced in different machines with different Linux distributions and
different JDK's.
Solr 3.3 and Lucidworks for solr 1.4.1 and 3.2.
was:
Linux.
Reproduced in different machines with different Linux distributions and
different JDK's.
Lucidworks for solr 1.4.1 and 3.2.
Affects Version/s: 3.3
I've done some more testing. For the following query, using edismax,
highlighting also fails in the same way:
http://localhost:8983/solr/select?q=%2binStock:true%20%2b_query_:%22{!edismax%20boost=$dateboost%20v=$qq}%22qq=testqf=nameq.alt=*:*tie=0.1dateboost=recip%28ms%28NOW,last_modified%29,3.16e-11,1,1%29hl=truehl.fl=name
While it works well for the following two queries:
http://localhost:8983/solr/select?q=%2binStock:true%20%2b_query_:%22{!edismax%20v=$qq}%22qq=testqf=nameq.alt=*:*tie=0.1dateboost=recip%28ms%28NOW,last_modified%29,3.16e-11,1,1%29hl=truehl.fl=name
http://localhost:8983/solr/select?q={!edismax%20boost=$dateboost%20v=$qq}%22qq=testqf=nameq.alt=*:*tie=0.1dateboost=recip%28ms%28NOW,last_modified%29,3.16e-11,1,1%29hl=truehl.fl=name
Also tested in solr 3.3 with the same results.
Highlighting does not work for embedded boost query that boosts a dismax query
--
Key: SOLR-2632
URL: https://issues.apache.org/jira/browse/SOLR-2632
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 1.4.1, 3.2, 3.3
Environment: Linux.
Reproduced in different machines with different Linux distributions and
different JDK's.
Solr 3.3 and Lucidworks for solr 1.4.1 and 3.2.
Reporter: Juan Antonio Farré Basurte
Priority: Minor
Labels: _query_, boost, dismax, edismax, embedded, highlighting,
hl.fl, query
I need to issue a dismax query, with date boost (I'd like to use the
multiplicative boost provided by boost queries) and also filtering for other
fields with too many possible distinct values to fit in a filter query. To
achieve this, I use the boost query as a nested query using the pseudofield
_query_. I also need highlighting for the fields used in the dismax query,
but highlighting does not work. If I just use the boosted dismax query
without embedding it inside another query, it works correctly. If I use bf
instead of a boost query, and embed directly the dismax query, it works too,
but hl.fl needs to be specified.
It's a bit complicated to explain, so, I'll give examples using the example
data that comes with solr (the problem is reproducible in the example solr
distribution, not only in my concrete project).
http://localhost:8983/solr/select?q=%2binStock:true%20%2b_query_:%22{!boost%20b=$dateboost%20v=$qq%20defType=dismax}%22qq=testqf=namedateboost=recip%28ms%28NOW,last_modified%29,3.16e-11,1,1%29hl=truehl.fl=name
For this query, highlighting does not work. Specifying hl.fl or not, does not
influence the result. The result is:
lst name=highlighting
lst name=GB18030TEST/
lst name=UTF8TEST/
/lst
http://localhost:8983/solr/select?q=_query_:%22{!boost%20b=$dateboost%20v=$qq%20defType=dismax}%22qq=testqf=namedateboost=recip%28ms%28NOW,last_modified%29,3.16e-11,1,1%29hl=truehl.fl=name
This doesn't work either. Same result.
http://localhost:8983/solr/select?q={!boost b=$dateboost v=$qq
defType=dismax}qq=testqf=namedateboost=recip(ms(NOW,last_modified),3.16e-11,1,1)hl=true
In this case, hightlighting works correctly:
lst name=highlighting
lst name=GB18030TEST
arr name=name
stremTest/em with some GB18030 encoded characters/str
/arr
/lst
lst name=UTF8TEST
arr name=name
stremTest/em with some UTF-8 encoded characters/str
/arr
/lst
/lst
http://localhost:8983/solr/select?q=%2BinStock:true%20%2B_query_:%22{!dismax%20v=$qq}%22qq=testqf=namebf=recip%28ms%28NOW,last_modified%29,3.16e-11,1,1%29hl=truehl.fl=name
This also works. Same result as before. But in this case hl.fl is needed.
Without it, highlighting does not work, either.
Thanks.
--
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-2399) Solr Admin Interface, reworked
[ https://issues.apache.org/jira/browse/SOLR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059244#comment-13059244 ] Uwe Schindler commented on SOLR-2399: - OK, will do once I have reviewed it locally. I have some small issues, but they are minor. Solr Admin Interface, reworked -- Key: SOLR-2399 URL: https://issues.apache.org/jira/browse/SOLR-2399 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Ryan McKinley Priority: Minor Fix For: 4.0 Attachments: SOLR-2399-110603-2.patch, SOLR-2399-110603.patch, SOLR-2399-110606.patch, SOLR-2399-110622.patch, SOLR-2399-110702.patch, SOLR-2399-admin-interface.patch, SOLR-2399-analysis-stopwords.patch, SOLR-2399-fluid-width.patch, SOLR-2399-sorting-fields.patch, SOLR-2399-wip-notice.patch, SOLR-2399.patch *The idea was to create a new, fresh (and hopefully clean) Solr Admin Interface.* [Based on this [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]] *Features:* * [Dashboard|http://files.mathe.is/solr-admin/01_dashboard.png] * [Query-Form|http://files.mathe.is/solr-admin/02_query.png] * [Plugins|http://files.mathe.is/solr-admin/05_plugins.png] * [Analysis|http://files.mathe.is/solr-admin/04_analysis.png] (SOLR-2476, SOLR-2400) * [Schema-Browser|http://files.mathe.is/solr-admin/06_schema-browser.png] * [Dataimport|http://files.mathe.is/solr-admin/08_dataimport.png] (SOLR-2482) * [Core-Admin|http://files.mathe.is/solr-admin/09_coreadmin.png] * [Replication|http://files.mathe.is/solr-admin/10_replication.png] * [Zookeeper|http://files.mathe.is/solr-admin/11_cloud.png] * [Logging|http://files.mathe.is/solr-admin/07_logging.png] (SOLR-2459) ** Stub (using static data) Newly created Wiki-Page: http://wiki.apache.org/solr/ReworkedSolrAdminGUI I've quickly created a Github-Repository (Just for me, to keep track of the changes) » https://github.com/steffkes/solr-admin -- 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-2878) Allow Scorer to expose positions and payloads aka. nuke spans
[ https://issues.apache.org/jira/browse/LUCENE-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059256#comment-13059256 ] Mike Sokolov commented on LUCENE-2878: -- bq. So PositionsInterators are never preserve positions for a document you pulled the interval for. You can basically pull the iterator only once and keep it until you scorer is exhausted. Bottom line here is that you are depending on the DocsAndPositionsEnum your TermScorer is using. Once this is advanced your positions are advanced too. We could think of a separate Enum here that advances independently, hmm that could actually work too, lets keep that in mind. So after working with this a bit more (and reading the paper), I see now that it's really not necessary to cache positions in the iterators. So never mind all that! In the end, for some uses like highlighting I think somebody needs to cache positions (I put it in a ScorePosDoc created by the PosCollector), but I agree that doesn't belong in the lower level iterator. bq. Eventually I think we can leave spans as they are right now and concentrate on the API / functionality, making things fast under the hood can be done later but getting things right to be flexible is the most important part here. As I'm learning more, I am beginning to see this is going to require sweeping updates. Basically everywhere we currently create a DocsEnum, we might now want to create a DocsAndPositionsEnum, and then the options (needs positions/payloads) have to be threaded through all the surrounding APIs. I wonder if it wouldn't make sense to encapsulate those options (needsPositions/needsPayloads) in some kind of EnumConfig object. Just in case, down the line, there is some other information that gets stored in the index, and wants to be made available during scoring, then the required change would be much less painful to implement. I'm thinking for example (Robert M's idea), that it might be nice to have a positions-offsets map in the index (this would be better for highlighting than term vectors). Maybe this would just be part of payload, but maybe not? And it seems possible there could be other things like that we don't know about yet? Allow Scorer to expose positions and payloads aka. nuke spans -- Key: LUCENE-2878 URL: https://issues.apache.org/jira/browse/LUCENE-2878 Project: Lucene - Java Issue Type: Improvement Components: core/search Affects Versions: Bulk Postings branch Reporter: Simon Willnauer Assignee: Simon Willnauer Labels: gsoc2011, lucene-gsoc-11, mentor Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878_trunk.patch, LUCENE-2878_trunk.patch, PosHighlighter.patch, PosHighlighter.patch Currently we have two somewhat separate types of queries, the one which can make use of positions (mainly spans) and payloads (spans). Yet Span*Query doesn't really do scoring comparable to what other queries do and at the end of the day they are duplicating lot of code all over lucene. Span*Queries are also limited to other Span*Query instances such that you can not use a TermQuery or a BooleanQuery with SpanNear or anthing like that. Beside of the Span*Query limitation other queries lacking a quiet interesting feature since they can not score based on term proximity since scores doesn't expose any positional information. All those problems bugged me for a while now so I stared working on that using the bulkpostings API. I would have done that first cut on trunk but TermScorer is working on BlockReader that do not expose positions while the one in this branch does. I started adding a new Positions class which users can pull from a scorer, to prevent unnecessary positions enums I added ScorerContext#needsPositions and eventually Scorere#needsPayloads to create the corresponding enum on demand. Yet, currently only TermQuery / TermScorer implements this API and other simply return null instead. To show that the API really works and our BulkPostings work fine too with positions I cut over TermSpanQuery to use a TermScorer under the hood and nuked TermSpans entirely. A nice sideeffect of this was that the Position BulkReading implementation got some exercise which now :) work all with positions while Payloads for bulkreading are kind of experimental in the patch and those only work with Standard codec. So all spans now work on top of TermScorer ( I truly hate spans since today ) including the ones that need Payloads (StandardCodec ONLY)!! I didn't bother to implement the other codecs yet since I want to get feedback on the API and on this first cut before I go one with it. I will
[jira] [Updated] (LUCENE-3167) Make lucene/solr a OSGI bundle through Ant
[ https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Stancapiano updated LUCENE-3167: - Comment: was deleted (was: Lucene uses the 2.3.4 version of maven-bundle-plugin. So it is better downlaod the 1.15.0 version of bndlib instead of the last. The download url for bndlib 1.15.0 will be: http://mirrors.ibiblio.org/pub/mirrors/maven2/biz/aQute/bndlib/1.15.0/bndlib-1.15.0.jar) Make lucene/solr a OSGI bundle through Ant -- Key: LUCENE-3167 URL: https://issues.apache.org/jira/browse/LUCENE-3167 Project: Lucene - Java Issue Type: New Feature Environment: bndtools Reporter: Luca Stancapiano We need to make a bundle thriugh Ant, so the binary can be published and no more need the download of the sources. Actually to get a OSGI bundle we need to use maven tools and build the sources. Here the reference for the creation of the OSGI bundle through Maven: https://issues.apache.org/jira/browse/LUCENE-1344 Bndtools could be used inside Ant -- 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
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059275#comment-13059275
]
Adriano Crestani commented on LUCENE-1768:
--
testInclusiveLowerRangeQuery and testInclusiveUpperRangeQuery are commented
since I found that StandardQueryParser is not supporting mixed include
syntaxes, such as {1 TO 2]. Shouldn't it be supported? I don't see why not.
I will take a look into it, thanks for reporting it, this might really be a bug
;)
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: Adriano Crestani
Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
Fix For: 4.0
Attachments: week1.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
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 9291 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9291/
1 tests failed.
FAILED: org.apache.solr.search.function.TestFunctionQuery.testGeneral
Error Message:
Exception during query
Stack Trace:
java.lang.RuntimeException: Exception during query
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:405)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:372)
at
org.apache.solr.search.function.TestFunctionQuery.testGeneral(TestFunctionQuery.java:306)
at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1430)
at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1348)
Caused by: java.lang.RuntimeException: REQUEST FAILED:
xpath=//float[@name='score']='7.0'
xml response was: ?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status0/intint
name=QTime2/int/lstresult name=response numFound=1 start=0
maxScore=-3.0docfloat name=id6.0/floatstr name=a_tcow cow cow
cow cow/strfloat name=score-3.0/float/doc/result
/response
request was:fl=*,scoreq={!func}totaltermfreq('a_t','cow')fq=id:6
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:398)
Build Log (for compile errors):
[...truncated 7921 lines...]
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1932) add relevancy function queries
[ https://issues.apache.org/jira/browse/SOLR-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059292#comment-13059292 ] Robert Muir commented on SOLR-1932: --- maybe add Terms.getSumTotalTermFreq (aka #tokens in field) too? usually if you use total term freq you also want #tokens as the denominator add relevancy function queries -- Key: SOLR-1932 URL: https://issues.apache.org/jira/browse/SOLR-1932 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Priority: Minor Fix For: 4.0 Attachments: SOLR-1932.patch, SOLR-1932_totaltermfreq.patch Add function queries for relevancy factors such as tf, idf, etc. -- 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-trunk - Build # 9291 - Failure
preflex, (it returns -1 as it doesnt support this statistic).
I'll add an assume to the test
On Sun, Jul 3, 2011 at 4:37 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9291/
1 tests failed.
FAILED: org.apache.solr.search.function.TestFunctionQuery.testGeneral
Error Message:
Exception during query
Stack Trace:
java.lang.RuntimeException: Exception during query
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:405)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:372)
at
org.apache.solr.search.function.TestFunctionQuery.testGeneral(TestFunctionQuery.java:306)
at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1430)
at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1348)
Caused by: java.lang.RuntimeException: REQUEST FAILED:
xpath=//float[@name='score']='7.0'
xml response was: ?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status0/intint
name=QTime2/int/lstresult name=response numFound=1 start=0
maxScore=-3.0docfloat name=id6.0/floatstr name=a_tcow cow cow
cow cow/strfloat name=score-3.0/float/doc/result
/response
request was:fl=*,scoreq={!func}totaltermfreq('a_t','cow')fq=id:6
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:398)
Build Log (for compile errors):
[...truncated 7921 lines...]
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2793) Directory createOutput and openInput should take an IOContext
[ https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated LUCENE-2793: -- Attachment: LUCENE-2793.patch I am not sure on the way I have tried to correct the nocommits on how to use buffer sizes based on IOContext. Let me know if this is not the correct way of doing it or are there any changes required. Directory createOutput and openInput should take an IOContext - Key: LUCENE-2793 URL: https://issues.apache.org/jira/browse/LUCENE-2793 Project: Lucene - Java Issue Type: Improvement Components: core/store Reporter: Michael McCandless Assignee: Varun Thacker Labels: gsoc2011, lucene-gsoc-11, mentor Attachments: LUCENE-2793-nrt.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch Today for merging we pass down a larger readBufferSize than for searching because we get better performance. I think we should generalize this to a class (IOContext), which would hold the buffer size, but then could hold other flags like DIRECT (bypass OS's buffer cache), SEQUENTIAL, etc. Then, we can make the DirectIOLinuxDirectory fully usable because we would only use DIRECT/SEQUENTIAL during merging. This will require fixing how IW pools readers, so that a reader opened for merging is not then used for searching, and vice/versa. Really, it's only all the open file handles that need to be different -- we could in theory share del docs, norms, etc, if that were somehow possible. -- 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-3274) Collapse Common module into Lucene core util
Collapse Common module into Lucene core util Key: LUCENE-3274 URL: https://issues.apache.org/jira/browse/LUCENE-3274 Project: Lucene - Java Issue Type: Improvement Reporter: Chris Male It was suggested by Robert in [http://markmail.org/message/wbfuzfamtn2qdvii] that we should try to limit the dependency graph between modules and where there is something 'common' it should probably go into lucene core. Given that I haven't added anything to this module except the MutableValue classes, I'm going to collapse them into the util package, remove the module, and correct the dependencies. -- 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 # 1614 - Still Failing
Build: https://builds.apache.org/job/Lucene-trunk/1614/ No tests ran. Build Log (for compile errors): [...truncated 9446 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3274) Collapse Common module into Lucene core util
[ https://issues.apache.org/jira/browse/LUCENE-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male updated LUCENE-3274: --- Attachment: LUCENE-3274.patch Patch which updates classes and dependencies. Everything compiles and passes. Collapse Common module into Lucene core util Key: LUCENE-3274 URL: https://issues.apache.org/jira/browse/LUCENE-3274 Project: Lucene - Java Issue Type: Improvement Reporter: Chris Male Attachments: LUCENE-3274.patch It was suggested by Robert in [http://markmail.org/message/wbfuzfamtn2qdvii] that we should try to limit the dependency graph between modules and where there is something 'common' it should probably go into lucene core. Given that I haven't added anything to this module except the MutableValue classes, I'm going to collapse them into the util package, remove the module, and correct the dependencies. -- 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-3274) Collapse Common module into Lucene core util
[
https://issues.apache.org/jira/browse/LUCENE-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059319#comment-13059319
]
Chris Male commented on LUCENE-3274:
Command for patch:
{code}
svn mkdir lucene/src/java/org/apache/lucene/util/mutable
svn move
modules/common/src/java/org/apache/lucene/common/mutable/MutableValue*.java
lucene/src/java/org/apache/lucene/util/mutable/
svn delete modules/common
svn delete dev-tools/maven/modules/common
svn delete dev-tools/idea/modules/common
{code}
Collapse Common module into Lucene core util
Key: LUCENE-3274
URL: https://issues.apache.org/jira/browse/LUCENE-3274
Project: Lucene - Java
Issue Type: Improvement
Reporter: Chris Male
Attachments: LUCENE-3274.patch
It was suggested by Robert in [http://markmail.org/message/wbfuzfamtn2qdvii]
that we should try to limit the dependency graph between modules and where
there is something 'common' it should probably go into lucene core. Given
that I haven't added anything to this module except the MutableValue classes,
I'm going to collapse them into the util package, remove the module, and
correct the dependencies.
--
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 # 9304 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9304/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull Error Message: CFS has no entries Stack Trace: java.lang.IllegalStateException: CFS has no entries at org.apache.lucene.store.CompoundFileWriter.close(CompoundFileWriter.java:139) at org.apache.lucene.store.CompoundFileDirectory.close(CompoundFileDirectory.java:181) at org.apache.lucene.store.DefaultCompoundFileDirectory.close(DefaultCompoundFileDirectory.java:58) at org.apache.lucene.index.SegmentMerger.createCompoundFile(SegmentMerger.java:139) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4252) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3863) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:37) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2715) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2710) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2706) at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3513) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2064) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2031) at org.apache.lucene.index.TestIndexWriterOnDiskFull.addDoc(TestIndexWriterOnDiskFull.java:539) at org.apache.lucene.index.TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull(TestIndexWriterOnDiskFull.java:74) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1277) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1195) Build Log (for compile errors): [...truncated 10601 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
