lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject [VOTE] SOLR-1602 Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Date Wed, 30 Dec 2009 17:16:56 GMT
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

  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.


Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message