[
https://issues.apache.org/jira/browse/SOLR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504068
]
Hoss Man commented on SOLR-135:
-------------------------------
>> yes, I like separate package names better.... but i'm worried about the
>> impact on dependent code.
>> ...
>> Are you suggesting its ok to move XML.java and SolrException.java to
>> o.a.s.common? That seems kinda extreme
>> for anyone using the classes...
I'm not sure. I think we've been talking for a long time about refactoring
some of the classes into different packages, which really only affects their
organization when developers look at them -- if we are now also looking at
reorganizing them into jars, and ensuring that certain subsets can be compiled
into their own jar with no dependencie on files not in that jar -- then i think
we might as well do both at once. I said, I could probably be convinced that
this isn't that important, and we should continue using the same package names
in a new src/common directory -- so perhaps a better question to ask is: do we
want to rework the packages too?"
Most of the classes you listed seem like perfect candidates for new "common"
package (or at the very least o.a.s.common.util, o.a.s.common.params), but i
have to admit i hadn't really considered SolrException ... on one hand it's
used so pervasively it should be considered "common" (not including it would
mean changing a *lot* of APIs of things we want to be able to include in the
common jar) on the other hand it does have very HTTP specific error codes in it.
Just spit balling here... what if o.a.s.common.SolrException was a base class
with no error codes (it looks like all of the "Common" classes just use
"BAD_REQUEST" at this point so refactoring it out would be clean, and the http
codes don't make sense in a 'common' context anyway) and
o.a.s.util.SolrException a real (non deprecated) subclass that adds the
ErrorCodes ... anyone catching util.SolrException is golden, anyone catching
common.SolrException can either infer an ErrorCode from context, or assume
BAD_REQUEST (a static utility in util.SolrException could make this easy by
wrapping the common.SolrException in a util.SolrException.
ugh.
> Restructure / Refactor codebase for shared libraries
> ----------------------------------------------------
>
> Key: SOLR-135
> URL: https://issues.apache.org/jira/browse/SOLR-135
> Project: Solr
> Issue Type: Wish
> Reporter: Ryan McKinley
> Priority: Minor
> Attachments: SOLR-135-RestructureForCommonJar.patch,
> SOLR-135-RestructureForCommonJar.patch, SOLR-135-RestructureForCommonJar.patch
>
>
> For SOLR-20 and other java projects, it would be nice to have common code
> share a codebase that does not require lucene or junit to compile.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
