[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795776#action_12795776
]
Chris A. Mattmann commented on SOLR-1602:
-----------------------------------------
bq. I've got no strong opinions about moving the code (it would probably be
easier to understand if we changed it, but so many people use IDEs these days
that i odn't know if it matters) but if we do change it i'd prefer to go the
deprecation route just out of consistency with how we've dealt with the
RequestHandlers and other utilities classes in the past - it's relatively
trivial to do, so there's very little down side - and while it's true someone
w/ deprecation warnings turned off probably won't notice - that's kind of the
point behind doing deprecations, you get them if you want, you ignore them if
you don't - but things don't break.
Thanks for the comments Hoss. As for deprecations I'm totally for them, when
the intention is to limit the impact on classes and code that has infected a
code base and the sheer impact of changing all of the package imports etc. is
so burndensome that you want to give someone some time to do it, while still
moving forward with the refactoring. I don't think that's the case here.
ResponseWriters aren't extensible as we've went back and forth all the time
about. I doubt many people have extended them. As far as writing their own, the
code is likely in their own package structure. So, I think in this case,
despite being different than what you guys have done before (which is a con),
the pro is the change is so minute and likely of little impact, we want the
compiler to throw an error or 2, so the user can fix those one or 2 and be set
for all future releases.
{quote}additionally: the config file issue should not be downplayed. yes it
would be a trivial search/replace, but that's precisely the reason why it would
aggravate users: because it would be such a trivial change w/o any obvious
benefit to the users.
(novice developers tend to be much more forgiving of eccentricities in the code
base then novice users are of upgrade incompatibilities)
{quote}
I'm just not seeing this. I'm a user of plenty of software and a developer of
the same. If someone told me I'd have to do a find/replace on a config file to
take advantage of a new version of software, and that find replace would have
the impact of 7 or 8 lines which I probably haven't touched in the config file
anyways I really wouldn't care (in other words the benefits far outweigh the
negatives). Though this is a generalization, I'd say on average, customers for
software I've developed over the last 10 years really haven't either.
If it makes you feel better I could strip out and upload a small patch that
only changes the sorlconfig.xml file part of this issue, and then in
CHANGES.txt we could reference this issue and tell the users, OK here's a quick
way to upgrade an existing deployment:
patch -p0 < curl
"https://issues.apache.org/jira/secure/attachment/12426188/SOLR-1602.configonly.patch.txt";
or something like that?
Oh, also I opened up a vote thread for this. If you get a chance could you vote
on it? Thanks a lot Hoss.
> 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.
