Maybe maven shade can help your situation ?
https://maven.apache.org/plugins/maven-shade-plugin/
http://stackoverflow.com/questions/13620281/what-is-the-maven-shade-plugin-used-for-and-why-would-you-want-to-relocate-java
Create a self-contained jar with guava package renamed.
Not very pretty but
What I am suggesting is that you set up a stand alone version of solr with
14.0.1 and run some sort of test suite similar to what you would normally use
solr for in your app. The replace the guava jar and re-run the tests. If all
works well, and I suspect it will because it did for me, then you
i can't run 14.0.1. that is the problem. 14 does not have the interfaces i
need
On Tue, May 26, 2015 at 10:28 AM, François Schiettecatte <
fschietteca...@gmail.com> wrote:
> Run whatever tests you want with 14.0.1, replace it with 18.0, rerun the
> tests and compare.
>
> François
>
> > On May 26,
Run whatever tests you want with 14.0.1, replace it with 18.0, rerun the tests
and compare.
François
> On May 26, 2015, at 10:25 AM, Robust Links wrote:
>
> by "dumping" you mean recompiling solr with guava 18?
>
> On Tue, May 26, 2015 at 10:22 AM, François Schiettecatte <
> fschietteca...@gm
by "dumping" you mean recompiling solr with guava 18?
On Tue, May 26, 2015 at 10:22 AM, François Schiettecatte <
fschietteca...@gmail.com> wrote:
> Have you tried dumping guava 14.0.1 and using 18.0 with Solr? I did a
> while ago and it worked fine for me.
>
> François
>
> > On May 26, 2015, at 1
Have you tried dumping guava 14.0.1 and using 18.0 with Solr? I did a while ago
and it worked fine for me.
François
> On May 26, 2015, at 10:11 AM, Robust Links wrote:
>
> i have a minhash logic that uses guava 18.0 method that is not in guava
> 14.0.1. This minhash logic is a separate maven p
I'm not aware of a way you can do this, other than upgrading the Guava
in Solr itself.
Or rather, you'd need to create your own classloader and load your own
instance of Guava using that rather than the default classloader. That's
possible, but would be rather ugly and complex.
I'd say research w
i have a minhash logic that uses guava 18.0 method that is not in guava
14.0.1. This minhash logic is a separate maven project. I'm including it in
my project via maven.the code is being used as a search component on the
set of results. The logic goes through the search results and deletes
duplicat
No, not really. Creating your own components that extend Solr is quite
acceptable - they can live in the Solr Home lib directory outside of the
war.
But really, if you are coding within Solr, you really need to use the
libraries that Solr uses. Or... create a JIRA ticket and help to upgrade
Solr t
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
i have custom search components.
On Tue, May 26, 2015 at 4:34 AM, Upayavira 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, 20
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 bas
12 matches
Mail list logo
