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