On Sat, May 3, 2008 at 11:30 AM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> A case in point is DataImportHandler (SOLR-469). As per our discussion
> with Grant Ingersoll, it makes a lot of sense to make this a contrib
> project rather than adding it to the core codebase.
I haven't h
On 3-May-08, at 9:27 PM, Noble Paul നോബിള്
नोब्ळ् wrote:
There is another class of patches like this RichDocumentRequestHandler
(SOLR-284) which brings in dependencies on other libraries, which can
safely live as a contrib project.
Do we need to raise a jira issue to track this (contrib cr
dy will have to put
that together.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Noble Paul നോബിള് नोब्ळ् <[EMAIL PROTECTED]>
> To: solr-dev@lucene.apache.org
> Sent: Sunday, May 4, 2008 6:27:32 AM
> Subject: Re: contr
me way, we can svn mv
> it and carry on.
>
> Otis
>
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
>
>
> - Original Message
> > From: Noble Paul നോബിള് नोब्ळ् <[EMAIL PROTECTED]>
> > To: solr-dev@lucene.apache
xt -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Noble Paul നോബിള് नोब्ळ् <[EMAIL PROTECTED]>
> To: solr-dev@lucene.apache.org
> Sent: Saturday, May 3, 2008 5:30:30 PM
> Subject: contrib for solr
>
> Hi Committers,
>
> As Solr
I think contrib is a good thing to consider. The DataImportHandler is
impressive, but huge. Although I think loading data from SQL should
be a 'core' feature, it makes sense to extract it.
As for packaging, 'contrib' features could be .jars that get dropped
into the lib directory, or coul
Hi Committers,
As Solr matures and the codebase grows, putting everything in the core
will lead to a bloat. This may impact our ability to have releases
early and often.
A case in point is DataImportHandler (SOLR-469). As per our discussion
with Grant Ingersoll, it makes a lot of sense to make t
