Build failed in Hudson: Solr-trunk #1017
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/1017/changes Changes: [yonik] SOLR-1586: add solr-internal tag [gsingers] small cleanups -- [...truncated 2333 lines...] [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 18.489 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 14.701 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.399 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 15.615 sec [junit] Running org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.11 sec [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.575 sec [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 17.857 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 50.188 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 101.656 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 48.942 sec [junit] Running org.apache.solr.client.solrj.embedded.TestSolrProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.621 sec [junit] Running org.apache.solr.client.solrj.request.TestUpdateRequestCodec [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.543 sec [junit] Running org.apache.solr.client.solrj.response.AnlysisResponseBaseTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.426 sec [junit] Running org.apache.solr.client.solrj.response.DocumentAnalysisResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.558 sec [junit] Running org.apache.solr.client.solrj.response.FieldAnalysisResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.558 sec [junit] Running org.apache.solr.client.solrj.response.QueryResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.264 sec [junit] Running org.apache.solr.client.solrj.response.TermsResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 11.569 sec [junit] Running org.apache.solr.client.solrj.response.TestSpellCheckResponse [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.636 sec [junit] Running org.apache.solr.client.solrj.util.ClientUtilsTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.571 sec [junit] Running org.apache.solr.common.SolrDocumentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.526 sec [junit] Running org.apache.solr.common.params.ModifiableSolrParamsTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.638 sec [junit] Running org.apache.solr.common.params.SolrParamTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.883 sec [junit] Running org.apache.solr.common.util.ContentStreamTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.56 sec [junit] Running org.apache.solr.common.util.DOMUtilTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.726 sec [junit] Running org.apache.solr.common.util.FileUtilsTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.353 sec [junit] Running org.apache.solr.common.util.IteratorChainTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.371 sec [junit] Running org.apache.solr.common.util.NamedListTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.437 sec [junit] Running org.apache.solr.common.util.TestFastInputStream [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.527 sec [junit] Running org.apache.solr.common.util.TestHash [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.7 sec [junit] Running org.apache.solr.common.util.TestNamedListCodec [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.93 sec [junit] Running org.apache.solr.common.util.TestXMLEscaping [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.915 sec [junit] Running org.apache.solr.core.AlternateDirectoryTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 10.989 sec [junit] Running org.apache.solr.core.AlternateIndexReaderTest [junit] Tests run: 1, Failures: 0,
[jira] Assigned: (SOLR-1682) Implement CollapseComponent
[ https://issues.apache.org/jira/browse/SOLR-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-1682: --- Assignee: Shalin Shekhar Mangar Implement CollapseComponent --- Key: SOLR-1682 URL: https://issues.apache.org/jira/browse/SOLR-1682 Project: Solr Issue Type: Sub-task Components: search Reporter: Martijn van Groningen Assignee: Shalin Shekhar Mangar Fix For: 1.5 Attachments: field-collapsing.patch Child issue of SOLR-236. This issue is dedicated to field collapsing in general and all its code (CollapseComponent, DocumentCollapsers and CollapseCollectors). The main goal is the finalize the request parameters and response format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1682) Implement CollapseComponent
[
https://issues.apache.org/jira/browse/SOLR-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1682:
Attachment: SOLR-236.patch
Here's an implementation based on [Yonik's
suggestion|https://issues.apache.org/jira/browse/SOLR-236?focusedCommentId=12792916page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12792916].
This is just a PoC and not fit to be committed. This implementation uses one
pass for collapse.threshold=1 and two passes for collapse.threshold1 so it
should be a lot faster than the previous method. Though, I haven't benchmarked
yet. Memory consumption should be proportional to start+count instead of index
size.
What is covered:
# Non-adjacent collapsing
# collapse.threshold
# [New response
format|https://issues.apache.org/jira/browse/SOLR-236?focusedCommentId=12793101page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12793101]
# Includes DocSetAwareCollector interface from SOLR-1680
What is not covered:
# Adjacent collapsing
# Aggregate functions (should be easy to add)
# Faceting (it doesn't keep/return the docsets needed for FacetComponent)
# Caching
# This implementation does not return the correct numFound
The response adds special fields to only the first document in a group. Here's
a sample of the first document in a group:
{code:xml}
doc
int name=id1/int
str name=name_s1author1/str
str name=title_s1a tree/str
date name=timestamp2009-12-30T10:16:51.944Z/date
arr name=multiDefault
strmuLti-Default/str
/arr
int name=intDefault42/int
str name=collapse.valueauthor1/str
int name=collapse.count1/int
float name=score0.67107505/float
/doc
{code}
See TestCollapseComponent.java for example usage.
Implement CollapseComponent
---
Key: SOLR-1682
URL: https://issues.apache.org/jira/browse/SOLR-1682
Project: Solr
Issue Type: Sub-task
Components: search
Reporter: Martijn van Groningen
Assignee: Shalin Shekhar Mangar
Fix For: 1.5
Attachments: field-collapsing.patch, SOLR-236.patch
Child issue of SOLR-236. This issue is dedicated to field collapsing in
general and all its code (CollapseComponent, DocumentCollapsers and
CollapseCollectors). The main goal is the finalize the request parameters and
response format.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795325#action_12795325 ] Grant Ingersoll commented on SOLR-773: -- SOLR-1586 is committed for GeohashField and SpatialTileField. We likely will add one more FieldType that combines both a 2D PointType and the tiling capabilities into a single FieldType, mostly as a convenience mechanism. Incorporate Local Lucene/Solr - Key: SOLR-773 URL: https://issues.apache.org/jira/browse/SOLR-773 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, lucene.tar.gz, screenshot-1.jpg, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, SOLR-773.patch, solrGeoQuery.tar, spatial-solr.tar.gz Local Lucene has been donated to the Lucene project. It has some Solr components, but we should evaluate how best to incorporate it into Solr. See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795341#action_12795341
]
Ryan McKinley commented on SOLR-1602:
-
Sounds fine... except for the back compatibility issues -- especially for
people upgrading with the same solrconfig.xml
When we moved all the handlers to a new package o.a.solr.handler, it left a
bunch of deprecated calsses in o.a.solr.request:
{code:java}
@Deprecated
public class StandardRequestHandler extends
org.apache.solr.handler.StandardRequestHandler {
// Don't use this class
}
{code}
Also, if we make a 'response' package, seems SolrQueryResponse.java should go
there.
Refactor SOLR package structure to include o.a.solr.response and move
QueryResponseWriters in there
---
Key: SOLR-1602
URL: https://issues.apache.org/jira/browse/SOLR-1602
Project: Solr
Issue Type: Improvement
Components: Response Writers
Affects Versions: 1.2, 1.3, 1.4
Environment: independent of environment (code structure)
Reporter: Chris A. Mattmann
Fix For: 1.5
Attachments: SOLR-1602.Mattmann.112509.patch.txt,
SOLR-1602.Mattmann.112509_02.patch.txt
Currently all o.a.solr.request.QueryResponseWriter implementations are
curiously located in the o.a.solr.request package. Not only is this package
getting big (30+ classes), a lot of them are misplaced. There should be a
first-class o.a.solr.response package, and the response related classes
should be given a home there. Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795346#action_12795346 ] Chris A. Mattmann edited comment on SOLR-1602 at 12/30/09 4:34 PM: --- Hi Ryan: Thanks. bq. Sounds fine... except for the back compatibility issues - especially for people upgrading with the same solrconfig.xml There are 8 response writers defined by default in solrconfig.xml. That doesn't seem too unwieldy a job for find/replace as far as configuration upgrades for someone moving from SOLR x.y to SOLR 1.5. As for code, yes, unfortunately users will have to recompile their response writers and update a few package names/imports per response writer which they'd probably want/have to do anyways on an upgrade regardless. bq. When we moved all the handlers to a new package o.a.solr.handler, it left a bunch of deprecated calsses in o.a.solr.request. You could certainly do this, and I've done it before in other projects. The tradeoff is, what type of message from the Java compiler do you want to notify you as a consumer of the SOLR java classes: # A deprecation (that could easily get swallowed if someone compiles with deprecation notifications off) # A compiler error, forcing the user to perform the small amount of legwork to update package refs I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. bq. Also, if we make a 'response' package, seems SolrQueryResponse.java should go there. Agreed, the patch I attached should move it there. was (Author: chrismattmann): Hi Ryan: Thanks. bq. Sounds fine... except for the back compatibility issues - especially for people upgrading with the same solrconfig.xml There are 8 response writers defined by default in solrconfig.xml. That doesn't seem too unwieldy a job for find/replace as far as configuration upgrades for someone moving from SOLR x.y to SOLR 1.5. As for code, yes, unfortunately users will have to recompile their response writers and update a few package names/imports per response writer which they'd probably want/have to do anyways on an upgrade regardless. bq. When we moved all the handlers to a new package o.a.solr.handler, it left a bunch of deprecated calsses in o.a.solr.request. You could certainly do this, and I've done it before in other projects. The tradeoff is, what type of message from the Java compiler do you want to notify you as a consumer of the SOLR java classes: # A deprecation (that could easily get swallowed if someone compiles with deprecation notifications off # A compiler error, forcing the user to perform the small amount of legwork to update package refs I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. bq. Also, if we make a 'response' package, seems SolrQueryResponse.java should go there. Agreed, the patch I attached should move it there. Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795346#action_12795346 ] Chris A. Mattmann commented on SOLR-1602: - Hi Ryan: Thanks. bq. Sounds fine... except for the back compatibility issues - especially for people upgrading with the same solrconfig.xml There are 8 response writers defined by default in solrconfig.xml. That doesn't seem too unwieldy a job for find/replace as far as configuration upgrades for someone moving from SOLR x.y to SOLR 1.5. As for code, yes, unfortunately users will have to recompile their response writers and update a few package names/imports per response writer which they'd probably want/have to do anyways on an upgrade regardless. bq. When we moved all the handlers to a new package o.a.solr.handler, it left a bunch of deprecated calsses in o.a.solr.request. You could certainly do this, and I've done it before in other projects. The tradeoff is, what type of message from the Java compiler do you want to notify you as a consumer of the SOLR java classes: # A deprecation (that could easily get swallowed if someone compiles with deprecation notifications off # A compiler error, forcing the user to perform the small amount of legwork to update package refs I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. bq. Also, if we make a 'response' package, seems SolrQueryResponse.java should go there. Agreed, the patch I attached should move it there. Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r894477 - /lucene/solr/trunk/src/java/org/apache/solr/search/function/distance/DistanceUtils.java
Hi Yonik,
What does this tag mean/do?
Cheers,
Chris
On 12/29/09 12:30 PM, yo...@apache.org yo...@apache.org wrote:
Author: yonik
Date: Tue Dec 29 20:30:53 2009
New Revision: 894477
URL: http://svn.apache.org/viewvc?rev=894477view=rev
Log:
SOLR-1586: add solr-internal tag
Modified:
lucene/solr/trunk/src/java/org/apache/solr/search/function/distance/DistanceUt
ils.java
Modified:
lucene/solr/trunk/src/java/org/apache/solr/search/function/distance/DistanceUt
ils.java
URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/search
/function/distance/DistanceUtils.java?rev=894477r1=894476r2=894477view=diff
==
---
lucene/solr/trunk/src/java/org/apache/solr/search/function/distance/DistanceUt
ils.java (original)
+++
lucene/solr/trunk/src/java/org/apache/solr/search/function/distance/DistanceUt
ils.java Tue Dec 29 20:30:53 2009
@@ -20,7 +20,8 @@
/**
- * Useful distance utiltities
+ * Useful distance utiltities.
+ * solr-internal: subject to change w/o notification.
*
**/
public class DistanceUtils {
++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.mattm...@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++
Re: svn commit: r894477 - /lucene/solr/trunk/src/java/org/apache/solr/search/function/distance/DistanceUtils.java
On Wed, Dec 30, 2009 at 11:43 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Yonik, What does this tag mean/do? It notifies anyone looking at it that it's subject to change w/o notification. We're primarily implementing higher-level features, not creating new low-level APIs, and I just wanted to make it clear that stuff like DistanceUtils is more implementation than interface and can change to meet the needs of the primary higher level APIs w/o the burden of back compat. -Yonik http://www.lucidimagination.com
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795352#action_12795352 ] Ryan McKinley commented on SOLR-1602: - | I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. +1 but since this is a breaking change -- that would need explicitly called out in CHANGES.txt, we should get pretty wide consensus before moving forward... Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795355#action_12795355 ] Chris A. Mattmann commented on SOLR-1602: - Hi Ryan: bq. but since this is a breaking change - that would need explicitly called out in CHANGES.txt, we should get pretty wide consensus before moving forward... +1, I'll call a vote. Cheers, Chris Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] SOLR-1602 Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Hi All, I've reported SOLR-1602, the jist of which is to move all the response writers into a new package, o.a.solr.response (and also move SolrQueryResponse in there). We know what's required to do this: SOLR-1602 proposed plan = 1. indicate this change in CHANGES.txt as a breaking change for any consumers of these classes from prior versions of SOLR 2. configuration update There are 8 response writers defined by default in solrconfig.xml. That doesn't seem too unwieldy a job for find/replace as far as configuration upgrades for someone moving from SOLR x.y to SOLR 1.5. Notify the users of this config update in CHANGES.txt. 3. code update for those folks who've implemented their own response writers As for code, yes, unfortunately users will have to recompile their response writers and update a few package names/imports per response writer which they'd probably want/have to do anyways on an upgrade regardless. Also notify the users of this required code update in CHANGES.txt. 4. regarding deprecation You could certainly leave present response classes in o.a.solr.request and make them extend the newly moved classes and deprecate those classes in o.a.solr.request (as specified in the issue comments), and I've done it before in other projects. The tradeoff is, what type of message from the Java compiler do you want to notify you as a consumer of the SOLR java classes: 1. A deprecation (that could easily get swallowed if someone compiles with deprecation notifications off) 2. A compiler error, forcing the user to perform the small amount of legwork to update package refs I'm a fan of 4.2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. Notify the users of this in CHANGES.txt = Here's what you're voting on: [ ] Yes, move forward with SOLR-1602 with the plan proposed above [ ] No, don't move forward with SOLR-1602 because... I'll leave the vote open for 72 hours. Votes from SOLR committers are binding, but everyone is welcome to voice your opinion. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: svn commit: r894477 - /lucene/solr/trunk/src/java/org/apache/solr/search/function/distance/DistanceUtils.java
Thanks, got it! Cheers, Chris On 12/30/09 8:53 AM, Yonik Seeley yo...@lucidimagination.com wrote: On Wed, Dec 30, 2009 at 11:43 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Yonik, What does this tag mean/do? It notifies anyone looking at it that it's subject to change w/o notification. We're primarily implementing higher-level features, not creating new low-level APIs, and I just wanted to make it clear that stuff like DistanceUtils is more implementation than interface and can change to meet the needs of the primary higher level APIs w/o the burden of back compat. -Yonik http://www.lucidimagination.com ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: [VOTE] SOLR-1602 Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Here's what you're voting on: [ x] Yes, move forward with SOLR-1602 with the plan proposed above [ ] No, don't move forward with SOLR-1602 because... I'll leave the vote open for 72 hours. Votes from SOLR committers are binding, but everyone is welcome to voice your opinion. Not to throw cold water on the formality... but.. when I suggested we get broader approval, i was not thinking about jumping into a formal vote... Seems odd to put a three day window while many people are on vacation :) ryan
Re: [VOTE] SOLR-1602 Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Hi Ryan, Not to throw cold water on the formality... but.. when I suggested we get broader approval, i was not thinking about jumping into a formal vote... Ah, the Apache way :) Seems odd to put a three day window while many people are on vacation :) I hear you, but based on mail traffic the past week or so it seems that many of the active committers (or at least a majority of them for SOLR [yonik, you, hoss, erik, grant, mark, shalin, noble]) are around... Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795371#action_12795371 ] Noble Paul commented on SOLR-1602: -- the patch does not apply. iis it not updated to trunk? Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795373#action_12795373 ] Chris A. Mattmann commented on SOLR-1602: - Hi Noble, bq. the patch does not apply. iis it not updated to trunk? Not sure, what message you getting? I'll take a look. I posted it originally in November so it's entirely possible it's out of date. Cheers, Chris Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] SOLR-1602 Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
I have not taken a look at the patch (could not apply it) . But I am in agreement with the idea of moving responsewriters to a new package. Just that the changes should be backward compatible On Wed, Dec 30, 2009 at 11:38 PM, Ryan McKinley ryan...@gmail.com wrote: Here's what you're voting on: [ x] Yes, move forward with SOLR-1602 with the plan proposed above [ ] No, don't move forward with SOLR-1602 because... I'll leave the vote open for 72 hours. Votes from SOLR committers are binding, but everyone is welcome to voice your opinion. Not to throw cold water on the formality... but.. when I suggested we get broader approval, i was not thinking about jumping into a formal vote... Seems odd to put a three day window while many people are on vacation :) ryan -- - Noble Paul | Systems Architect| AOL | http://aol.com
[jira] Assigned: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1602: Assignee: Noble Paul Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key values
pairs in the json.
For example, the text:
{code}
{ hello: world, rank:5 }
{code}
gets indexed as two tokens:
|| term position | 1 | 2 |
|| term text | hello:world | rank:5 |
|| term type | word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
[
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1690:
Attachment: SOLR-1690-JSONKeyValueTokenizerFactory.patch
Here is a simple JSON tokenizer. No tests, but a good place to start if you
are looking to do something similar.
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Attachments: SOLR-1690-JSONKeyValueTokenizerFactory.patch
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key
values pairs in the json.
For example, the text:
{code}
{ hello: world, rank:5 }
{code}
gets indexed as two tokens:
|| term position |1 | 2 |
|| term text |hello:world | rank:5 |
|| term type |word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
[
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1690:
Attachment: noggit-1.0-A1.jar
This tokenizer uses noggit
http://svn.apache.org/repos/asf/labs/noggit/
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Attachments: noggit-1.0-A1.jar,
SOLR-1690-JSONKeyValueTokenizerFactory.patch
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key
values pairs in the json.
For example, the text:
{code}
{ hello: world, rank:5 }
{code}
gets indexed as two tokens:
|| term position |1 | 2 |
|| term text |hello:world | rank:5 |
|| term type |word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
[
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1690:
Description:
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key values
pairs in the json.
{code:xml|title=schema.xml}
!-- JSON Field Type --
fieldtype name=json class=solr.TextField positionIncrementGap=100
omitNorms=true
analyzer type=index
tokenizer class=solr.JSONKeyValueTokenizerFactory keepArray=true
hierarchicalKey=false/
filter class=solr.TrimFilterFactory/
filter class=solr.LowerCaseFilterFactory/
/analyzer
analyzer type=query
tokenizer class=solr.KeywordTokenizerFactory/
filter class=solr.TrimFilterFactory /
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldtype
{code}
Given text:
{code}
{ hello: world, rank:5 }
{code}
indexed as two tokens:
|| term position | 1 | 2 |
|| term text | hello:world | rank:5 |
|| term type | word | word |
|| source start,end | 12,17 | 27,28 |
was:
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key values
pairs in the json.
For example, the text:
{code}
{ hello: world, rank:5 }
{code}
gets indexed as two tokens:
|| term position | 1 | 2 |
|| term text | hello:world | rank:5 |
|| term type | word | word |
|| source start,end | 12,17 | 27,28 |
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Attachments: noggit-1.0-A1.jar,
SOLR-1690-JSONKeyValueTokenizerFactory.patch
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key
values pairs in the json.
{code:xml|title=schema.xml}
!-- JSON Field Type --
fieldtype name=json class=solr.TextField positionIncrementGap=100
omitNorms=true
analyzer type=index
tokenizer class=solr.JSONKeyValueTokenizerFactory keepArray=true
hierarchicalKey=false/
filter class=solr.TrimFilterFactory/
filter class=solr.LowerCaseFilterFactory/
/analyzer
analyzer type=query
tokenizer class=solr.KeywordTokenizerFactory/
filter class=solr.TrimFilterFactory /
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldtype
{code}
Given text:
{code}
{ hello: world, rank:5 }
{code}
indexed as two tokens:
|| term position |1 | 2 |
|| term text |hello:world | rank:5 |
|| term type |word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795431#action_12795431 ] Chris A. Mattmann commented on SOLR-1602: - Hey Ryan, You are exactly right. When I created the patch in Eclipse, it negated to do the add +++ part of the patch b/c it saw the files as getting moved. Note that's why the patch doesn't apply -- it tries to make changes to the response writer class packages based on the path org/apache/solr/response/WriterName.java, which doesn't exist yet. To apply this patch: 1. first move the response writers into a new folder (response). Also copy SolrQueryResponse there. 2. apply the patch Cheers, Chris Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795428#action_12795428 ] Ryan McKinley commented on SOLR-1602: - | the patch does not apply. iis it not updated to trunk? I've never had good luck with patches for moving files. Even if it applies correctly, if you commit the patch, the svn history does not show that the file was moved. (unless this has been fixed in the last year since i looked) For refactoring like this, whoever commits this will probably need to make the changes directly. Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
