duplication in client/ruby/solrb/solr ?

[Chris Hostetter <ho...@fucit.org>]

Erik: doing my first "svn update" since you started working on the flare
stuff, i noticed a lot of files commited into client/ruby/solrb/ that
seem to be duplicates of other files from the repository ...
client/ruby/solrb/solr actually seems to be a duplicated copy of example
with some minor changes to the schema.xml and solrconfig.xml ... all
of the jetty jars are commited into client/ruby/solrb/solr/ext/, there's
even a client/ruby/solrb/solr/webapps/solr.war

I don't really get Ruby or Rails, so maybe i'm missing something about why
you need another copy of these files -- but couldn't they be copied into
place by an ant target instead of commiting duplicate copies?



-Hoss

Re: duplication in client/ruby/solrb/solr ?

[Mike Klaas <mi...@gmail.com>]

On 1/3/07, Erik Hatcher <er...@ehatchersolutions.com> wrote:
> On Jan 3, 2007, at 8:18 PM, Chris Hostetter wrote:

> > I don't really get Ruby or Rails, so maybe i'm missing something
> > about why
> > you need another copy of these files -- but couldn't they be copied
> > into
> > place by an ant target instead of commiting duplicate copies?
>
> I wanted to lock in a version of Solr to avoid it being a moving
> target.  I'm not quite sure I understand what you mean about copying
> using Ant.  Ant isn't involved in the Ruby world (unless we develop
> some custom request handlers or something like that, specific to the
> Ruby stuff).

Might labs.apache.org make sense for this project?

-Mike

Re: duplication in client/ruby/solrb/solr ?

[Chris Hostetter <ho...@fucit.org>]

: > place by an ant target instead of commiting duplicate copies?
:
: I wanted to lock in a version of Solr to avoid it being a moving
: target.  I'm not quite sure I understand what you mean about copying
: using Ant.  Ant isn't involved in the Ruby world (unless we develop
: some custom request handlers or something like that, specific to the
: Ruby stuff).

i ment as part of a new ant target "setup-ruby" or something that could
copy the neccessary files into the needed locations (much the way "ant
example" currently does) but if your goal is to have a locked down version
of solr and to allow people to cheeck out client/ruby and have a self
contained sandbox to play with then i understand why you did it this way.

: with the desired configuration.  I don't envision having the entire
: Solr application under the Ruby code permanently, mainly for folks to
: jump into it and help out as easily as possible.

that sounds fine to me ... i just wanted to clarify why they were all
there.



-Hoss

Re: duplication in client/ruby/solrb/solr ?

[Erik Hatcher <er...@ehatchersolutions.com>]

On Jan 3, 2007, at 8:18 PM, Chris Hostetter wrote:
> Erik: doing my first "svn update" since you started working on the  
> flare
> stuff, i noticed a lot of files commited into client/ruby/solrb/ that
> seem to be duplicates of other files from the repository ...
> client/ruby/solrb/solr actually seems to be a duplicated copy of  
> example
> with some minor changes to the schema.xml and solrconfig.xml ... all
> of the jetty jars are commited into client/ruby/solrb/solr/ext/,  
> there's
> even a client/ruby/solrb/solr/webapps/solr.war
>
> I don't really get Ruby or Rails, so maybe i'm missing something  
> about why
> you need another copy of these files -- but couldn't they be copied  
> into
> place by an ant target instead of commiting duplicate copies?

I wanted to lock in a version of Solr to avoid it being a moving  
target.  I'm not quite sure I understand what you mean about copying  
using Ant.  Ant isn't involved in the Ruby world (unless we develop  
some custom request handlers or something like that, specific to the  
Ruby stuff).

My consideration was primarily for those that will svn checkout from  
client/ruby and below, and being able to have Solr up and running  
easily.

There will at least be custom configuration for Solr with  
solrconfig.xml and schema.xml involved in the Ruby effort.

I'm open to suggestions for improvement, if there is a cleaner way to  
allow folks trying this out to easily bootstrap into a Solr instance  
with the desired configuration.  I don't envision having the entire  
Solr application under the Ruby code permanently, mainly for folks to  
jump into it and help out as easily as possible.

	Erik