You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Ryan McKinley <ry...@squid-labs.com> on 2007/04/21 20:43:36 UTC

solr-util.jar

I'm looking at SOLR-20 and SOLR-135.  It would be nice to have have many 
interface/utility classes in an independant library without lucene, 
solr, or junit dependancies.

I thought this could be as simple as putting o.a.s.util in its own jar 
file - but there are a bunch of dependencies that make that difficult.

Is it a bad idea to split classes in a package across multiple jar 
files?  For example, could we put:
  o.a.s.core.SolrException
  o.a.s.handler.UpdateParams
  o.a.s.request.SolrParams
  o.a.s.util.* (except for some things)

in solr-util.jar?

I haven't seen anyone else do this...

The alternative is to refactor things so that o.a.s.util can be 
independent, but that seems a bit drastic.

thoughts?



Re: solr-util.jar

Posted by Chris Hostetter <ho...@fucit.org>.
: The alternative is to refactor things so that o.a.s.util can be
: independent, but that seems a bit drastic.

if we want an isolatable jar we should probably refactor these things out
... the java package isn't as important to the refactoring as the source
path and compilation, ie: move the classes in question out of src/java and
into some new src/util, compile src/util into it's own jar (with no
classpath) prior to compileing src/java (with the new util jar in that
compilation classpath)



-Hoss