Yeah, longer term, the plugin stuff seems like another area we should let some kind of container manage (OSGi or Spring or something).
-Yonik On Mon, Dec 15, 2008 at 2:16 PM, Grant Ingersoll <gsing...@apache.org> wrote: > 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 <hossman_luc...@fucit.org> >>> To: solr-dev@lucene.apache.org >>> 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 > > > > > > > > > > >
