Re: [jira] Updated: (SOLR-20) A simple Java client with Java APIs for add(), delete(), commit() and optimize().

[Erik Hatcher]

On Jun 2, 2006, at 1:35 PM, Darren Vengroff wrote:
I wasn't thrilled about the XML dependency either, but it I figured  
using
the class already present in solr was better than adding new code (or
ripping off code I've written elsewhere) that does more or less the  
same
thing.
In situations like this I tend to go for a three jar approach, with  
a common
jar with stuff like XML in it, and then independent client and  
server jars
built on top of that.  It might be overkill in this case, given  
there is
only one small client class, but it is an option.

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.

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.

Maven2, by the way, is really good at managing that kind of  
interdependent
set of jars.  But I realize that I got ahead of myself when I proposed
http://issues.apache.org/jira/browse/SOLR-19?page=all.  I've since  
made
improvements that make it much easier for me to use solr in my
all-Maven2-all-the-time world, but it's somewhat unreasonable to  
push it
back on a community that is happy with ant.

I must admit a strong bias against Maven due to my deep ties with  
Ant, but the last time I tried it I was using the first version of  
Maven.  Maven2 has gotten a lot of good PR and is well worth  
considering for Solr and my own Java projects.  At the moment, I  
stick with raw Lucene, Solr, and Ruby on Rails so I don't deal with a  
whole lot of dependencies thankfully.

        Erik