[ 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.