Right, and that applies not only to Lucene, but any other dependency. SpringBoot is a "single class path" technology. Perhaps attempting a "single class path" goal for a product is always futile in Java, because eventually you run into incompatibilities. Luckily for me, I don't need a *different* version of Lucene than the one included via JackrabbitOak dependencies. Indeed all the searching and data access in meta64 comes directly from Oak and only from Oak, to the concept of having a different lucene version seems unlikely. Perhaps I should just start using Felix just in case, so I am covered in any event. I'm not sure how I'd run a SpringBoot app inside OSGi, but I guess there is a way...
Best regards, Clay Ferguson [email protected] On Thu, Aug 6, 2015 at 9:12 AM, Torgeir Veimo <[email protected]> wrote: > On 5 August 2015 at 18:43, Bertrand Delacretaz <[email protected]> > wrote: > > And on top of that, as you say, when one needs to integrate > > legacy/ugly code OSGi can be a lifesaver. > > Actually, OSGi is a requirement if integrating oak-lucene with any > code that uses lucene, as oak-lucene is hard coded to lucene 4.7.1, > and even includes lucene classes directly. I'd actually label > oak-lucene the 'legacy' component here. > > > -- > -Tor >
