Just to add some more fun to the mix:
I think, eventually, and I really hate to say this b/c classloading is
a nightmare, but we may want to look into isolated classloaders or
OSGi or something for the Solr Home lib directory. The benefits being
that I already see library collisions in our future.
On Dec 15, 2008, at 12:50 PM, Otis Gospodnetic wrote:
For what it's worth, I'm pro keeping contrib things in their own
jars. It's easy to figure out what you need to include when/if you
need it, but it pains me to carry around jars with code that I have
absolutely no need for.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
----- Original Message ----
From: Chris Hostetter <[email protected]>
To: [email protected]
Sent: Saturday, December 13, 2008 2:12:01 AM
Subject: Re: ant example, tika
: The only issue I see now is that DIH has been released as part of
the core, so
: I would vote that it stays in there. It is also quite popular, I
think, so
: I'd hate to break people.
...which is why having a kitchen-sink war with all the contribs
might make
sense. But frankly i don't see it as a very problematic to
document how
to use a DIH jar for people who upgrade ... we have to document how
to use
contribs in general.
-Hoss
--------------------------
Grant Ingersoll
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
