: Sounds like we need a client with the code that is not shared within : the Solr server, a Solr JAR that is shared across both the client and : server, and then whatever other dependencies we need like the pull : parser.
I think the org.apache.solr.util package may be the right boundray ... the build process for "Solr core" could generate a solr-util.jar which contains all of that code, and a solr.war (which also contains that solr-util.jar for use within the Solr) external clients could then use solr-util.jar as needed. : With Yonik's further directions with this sort of thing, I think the : best thing for now is to go with his recommendation of putting it in : a contrib directory and letting this stuff evolve. I do see it : eventually fitting into some core kinda of library without the : "contrib" label. I personally don't have an opinion about a "contrib" label .. but as we talk about making a place for client library code, I wonder wether we want to distiguish client code intended for executing queries vs. client code intended for executing updates? (vs. client code that encapsulates both) ... should we encourage a seperation? -Hoss
