I guess this is one reason why the whole WAR approach is being removed! Solr should be a black-box that you talk to, and get responses from. What it depends on and how it is deployed, should be irrelevant to you.
If you are wanting to override the version of guava that Solr uses, then you'd have to rebuild Solr (can be done with maven) and manually update the pom.xml to use guava 18.0, but why would you? You need to test Solr completely (in case any guava bugs affect Solr), deal with any build issues that arise (if guava changes any APIs), and cause yourself a world of pain, for what gain? On 26 May 2015 at 11:29, Robust Links <pey...@robustlinks.com> wrote: > i have custom search components. > > On Tue, May 26, 2015 at 4:34 AM, Upayavira <u...@odoko.co.uk> wrote: > > > Why is your app tied that closely to Solr? I can understand if you are > > talking about SolrJ, but normal usage you use a different application in > > a different JVM from Solr. > > > > Upayavira > > > > On Tue, May 26, 2015, at 05:14 AM, Robust Links wrote: > > > I am stuck in Yet Another Jarmagedon of SOLR. this is a basic > question. i > > > noticed solr 5.0 is using guava 14.0.1. My app needs guava 18.0. What > is > > > the pattern to override a jar version uploaded into jetty? > > > > > > I am using maven, and solr is being started the old way > > > > > > java -jar start.jar > > > -Dsolr.solr.home=... > > > -Djetty.home=... > > > > > > I tried to edit jetty's start.config (then run java > > > -DSTART=/my/dir/start.config > > > -jar start.jar) but got no where... > > > > > > any help would be much appreciated > > > > > > Peyman > > >
