[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795896#action_12795896
]
Chris A. Mattmann edited comment on SOLR-1602 at 1/3/10 4:47 AM:
-----------------------------------------------------------------
bq. my question is .WHY? to change a few files from one package to another? The
user may not even care if the entire all classes are put into one package .
My question is since when are code-level and architecture-level design
decisions for a software system directly dictated by the end users of your
application? At NASA, I don't consult end users of the software I develop
regarding the organization of the software's code structure. End-user concerns
are mostly with functional properties (performability, scalability, etc...)
with a few NFP's sprinkled in (extensibility, ease of use, configurability,
etc.), and not design decisions. While it is true that these concerns have a
great impact on the software system's architecture, the notion of code-level
organization is a bit orthogonal. However, that doesn't mean that design
decisions (or improvements) shouldn't be made. Modern distributed software has
many stakeholders, including end-users, software developers, architects,
managers, etc. This is clearly addressing a concern of a few of those
stakeholders (architects, developers [you could argue either end of this],
managers [who may market the software and where clean organization is something
they'd like to add as a selling point], but end-users are not really one of
them in this case I'll agree).
Ultimately because of this, the goal is to reap the benefits of good design and
code organization within acceptable bounds to the user. That's really the
discussion point at hand. I believe acceptable bounds to be:
# Remove the classes from the package structure right now to deal with this
move swiftly and reduce confusion (i.e., why are there 2 copies of the same
class, in different packages?) Admittedly, this is an
architect/developer/manager issue more so than an end-user one.
# Provide a simple, 1 line upgrade script that end-users can upgrade their
solrconfig.xml file with. That way when and if they employ the approach you
mentioned Noble (i.e., copying their old configuration), there is minute
additional effort to upgrade the config.
I've done the deprecation route on one of my projects at NASA 7-8 years ago in
a highly similar situation. In fact, it was way more extreme. We moved most of
our core Java classes (100s of them) from a top-level package to another
top-level package. In doing so, we kept replicas of the Java classes in the old
package structure using the extends structure with deprecations as shown by
Ryan above. We saw 0 measurable benefit of doing this, and we had 100s-1000s of
end users of the software across many NASA centers and external organizations.
And to me, it was just an organizational mess that caused confusion among new
developers we hired to evolve the code. So, I just don't see the benefit. From
a code management point of view it added extra work to the
developer/architect/manager stakeholders more than anything else.
Cheers,
Chris
was (Author: chrismattmann):
bq. my question is .WHY? to change a few files from one package to another?
The user may not even care if the entire all classes are put into one package .
My question is since when are code-level and architecture-level design
decisions for a software system directly dictated by the end users of your
application? At NASA, I don't consult end users of the software I develop
regarding the organization of the software's code structure. End-user concerns
are mostly with functional properties (performability, scalability, etc...)
with a few NFP's sprinkled in (extensibility, ease of use, configurability,
etc.), and not design decisions. While it is true that these concerns have a
great impact on the software system's architecture, the notion of code-level
organization is a bit orthogonal. However, that doesn't mean that design
decisions (or improvements) shouldn't be made. Modern distributed software has
many stakeholders, including end-users, software developers, architects,
managers, etc. This is clearly addressing a concern of a few of those
stakeholders (architects, developers [you could argue either end of this],
managers [who may market the software and where clean organization is something
they'd like to add as a selling point], but end-users are not really one of
them in this case I'll agree).
Ultimately because of this, the goal is to reap the benefits of good design and
code organization within acceptable bounds to the user. That's really the
discussion point at hand. I believe acceptable bounds to be:
# Remove the classes from the package structure right now to deal with this
move swiftly and reduce confusion (where are there 2 copies of the same class,
in different packages?) Admittedly, this is an architect/developer/manager
issue more so than an end-user one.
# Provide a simple, 1 line upgrade script that end-users can upgrade their
solrconfig.xml file with. That way when and if they employ the approach you
mentioned Noble (i.e., copying their old configuration), there is minute
additional effort to upgrade the config.
I've done the deprecation route on one of my projects at NASA 7-8 years ago in
a highly similar situation. In fact, it was way more extreme. We moved most of
our core Java classes (100s of them) from a top-level package to another
top-level package. In doing so, we kept replicas of the Java classes in the old
package structure using the extends structure with deprecations as shown by
Ryan above. We saw 0 measurable benefit of doing this, and we had 100s-1000s of
end users of the software across many NASA centers and external organizations.
And to me, it was just an organizational mess that caused confusion among new
developers we hired to evolve the code. So, I just don't see the benefit. From
a code management point of view it added extra work to the
developer/architect/manager stakeholders more than anything else.
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, upgrade_solr_config
>
>
> 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.
