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*
On 5 August 2015 at 18:43, Bertrand Delacretaz 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,
an
On Tue, Aug 4, 2015 at 5:08 PM, Clay Ferguson wrote:
> ...I think *the* primary reason OSGi has a place in the world, is because it
> can make completely incompatible set of things be able to run together...
That's one aspect of OSGi, but our experience with Sling is that OSGi
is also a fantastic
Hi Clay,
On Tue, 2015-08-04 at 10:08 -0500, Clay Ferguson wrote:
> Robert,
> Not to turn this email list into a theoretical discussion, but I'll
> say one thing, and then we can carry on the conversation privately or
> in different forum...
>
> I think *the* primary reason OSGi has a place in t
On Tue, 2015-08-04 at 15:45 +, Justin Edelson wrote:
> Hi,
> I don't think Robert (or anyone else) is saying that there shouldn't
> be a Spring Boot-based distribution which uses Oak. But the
> Jackrabbit project wouldn't necessarily be the right place for this.
Precisely :-)
Robert
>
> R
​Justin,
Correct. I was laying out the details of how JCR should relate to
SpringBoot. I think I got it right. SpringBoot would include a JCR project,
not the other way around. Jackrabbit would never depend on SpringBoot.
However, if I were the architect of Oak, it would be using Spring Core
(etc)
Hi,
I don't think Robert (or anyone else) is saying that there *shouldn't* be a
Spring Boot-based distribution which uses Oak. But the Jackrabbit project
wouldn't necessarily be the right place for this.
Regards,
Justin
On Tue, Aug 4, 2015 at 10:08 AM Clay Ferguson wrote:
> Robert,
> Not to tur
Robert,
Not to turn this email list into a theoretical discussion, but I'll say one
thing, and then we can carry on the conversation privately or in different
forum...
I think *the* primary reason OSGi has a place in the world, is because it
can make completely incompatible set of things be able t
On Mon, Aug 3, 2015 at 8:14 AM, Clay Ferguson wrote:
> I looked at that readme page (oak-pojosr). I like the idea of simplifying
> use of osgi, or embedding it. It reminds me a bit of how SpringBoot actually
> embeds an instance of Tomcat, so deployment is simple and easy for web apps.
>
> Having
I looked at that readme page (oak-pojosr). I like the idea of simplifying
use of osgi, or embedding it. It reminds me a bit of how SpringBoot
actually embeds an instance of Tomcat, so deployment is simple and easy for
web apps.
Having a totally prepackaged way of doing stuff is what most developer
Thanks Clay for putting this together. Current documentation is not
good for standalone usage as quite a bit of logic of configuring Oak
is based on OSGi. Due to that using Oak as is in standalone
environment is tricky
The oak-pojosr [1] was intended to enable use of Oak with all its OSGi
based co
Fellow Jackrabbits,
I discovered it was a *huge* effort and there is a *huge* lack in the
examples related to simply getting MongoDb up and running (as JCR) with
Lucene indexes getting properly used. Since this effort took me 2 solid
days and there are no great examples that come up via google i'm
12 matches
Mail list logo
