lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Date Sat, 02 Jan 2010 19:15:54 GMT

    [ 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/2/10 7:15 PM:
-----------------------------------------------------------------

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


      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 design decisions for a software system dictated by the end users
of your application? In other words, the two concerns are orthogonal. 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. 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.


Mime
View raw message