JCR + MongoDb + Lucene Holy Grail Finally Found

[Clay Ferguson <wc...@gmail.com>]

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 sharing my
example:

This code creates a Full Text Search on jcr:content, and an sorting
capability on jcr:lastModified:

https://github.com/Clay-Ferguson/meta64/blob/master/src/main/java/com/meta64/mobile/repo/OakRepository.java

I also just updated meta64 project to be using the 1.0.18 branch of the
Jackrabbit code, so it's all up to date stuff. I would highly recommend
adding this or a similar example right onto the Lucene page of the Oak
docs, because what I'm doing is exactly what everyone else wants, and
the documentation itself is just completely confusing and mind boggling
without a real example.

Cheers, and happy jackrabbiting.

Best regards,
Clay Ferguson
wclayf@gmail.com
meta64.com​

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Robert Munteanu <ro...@apache.org>]

On Tue, 2015-08-04 at 15:45 +0000, 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

> 
> Regards,
> Justin
> 
> On Tue, Aug 4, 2015 at 10:08 AM Clay Ferguson <wc...@gmail.com> 
> 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 the world, is 
> > because it can make completely incompatible set of things be able 
> > to run together. For example, if I have component A that requires 
> > version B of of some specific class but perhaps B is using an older 
> > component C than the version of C that A is using internally...then 
> > a single classpath cannot ever work. You must have an environment 
> > which gives each component it's own "world (i.e. separate 
> > classpath)" or environment to run in. 
> > 
> > What SpringBoot is all about, on the other hand, is saying let's 
> > design a single set of dependencies (Technology Stack) that are all 
> > *known* to work together (single classloader) on the same versions 
> > of all dependencies in the chain, and eliminate the version 
> > conflicting before it starts, thus eliminating *one of* the 
> > problems OSGi solves. So OSGi is great, but unless I run directly 
> > into one of the problems it solves, I don't need it. Spring already 
> > has "Spring Data MongoDB" and "Spring Data Solr" projects, and I 
> > think there should be a "Spring Data JCR" project also, that is 
> > basically JackrabbitOak packaged similarly to how I do it in 
> > meta64.com. That is, basically Oak dependencies, with a thin layer 
> > of spring beans exposing it, and a bit of AOP for session 
> > management, etc.
> > 
> > My apologies if this is an inappropriate forum for such a 
> > discussion.
> > 
> > Best regards,
> > Clay Ferguson
> > wclayf@gmail.com
> > 
> > 
> > On Tue, Aug 4, 2015 at 9:04 AM, Robert Munteanu <ro...@lmn.ro> 
> > wrote:
> > > On Mon, Aug 3, 2015 at 8:14 AM, Clay Ferguson <wc...@gmail.com> 
> > > 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 a totally prepackaged way of doing stuff is what most 
> > > developers want
> > > > these days. There are just too many moving parts in most large 
> > > systems, so
> > > > people need "prepackaged" configurations that just work right 
> > > out of the
> > > > box, at least for some minimal set of the most common usage 
> > > patterns. I'm
> > > > not sure if there's any plans to integrate into SpringBoot, but 
> > > IMO that
> > > > would be a hugely important thing for the industry if Oak was 
> > > part of
> > > > SpringBoot stack.
> > > 
> > > I'm not an Oak developer, so don't take this as any sort of 
> > > official
> > > statement, but the way I understand it the Jackrabbit project 
> > > only
> > > provides the Oak code / binaries ; packaging it in suitable 
> > > formats
> > > for development / deployment is left to packagers / other 
> > > projects.
> > > 
> > > One such example is Apache Sling ( https://sling.apache.org ), a
> > > framework built on top of JCR, REST and OSGi. But if you're
> > > well-versed in Spring and convinced that you should switch to 
> > > OSGi it
> > > won't help you much. In that case "someone" ( it's always someone 
> > > else
> > > :-) ) should provide that integration.
> > > 
> > > Cheers,
> > > 
> > > Robert
> > > --
> > > Sent from my (old) compute
> > > 
> > 

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Clay Ferguson <wc...@gmail.com>]

​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) internally nearly everywhere. :)

Best regards,
Clay Ferguson
wclayf@gmail.com


On Tue, Aug 4, 2015 at 10:45 AM, Justin Edelson <ju...@justinedelson.com>
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.
>
> Regards,
> Justin
>
> On Tue, Aug 4, 2015 at 10:08 AM Clay Ferguson <wc...@gmail.com> 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 the world, is because it
>> can make completely incompatible set of things be able to run together. For
>> example, if I have component A that requires version B of of some specific
>> class but perhaps B is using an older component C than the version of C
>> that A is using internally...then a single classpath cannot ever work. You
>> must have an environment which gives each component it's own "world (i.e.
>> separate classpath)" or environment to run in.
>>
>> What SpringBoot is all about, on the other hand, is saying let's design a
>> single set of dependencies (Technology Stack) that are all *known* to work
>> together (single classloader) on the same versions of all dependencies in
>> the chain, and eliminate the version conflicting before it starts, thus
>> eliminating *one of* the problems OSGi solves. So OSGi is great, but unless
>> I run directly into one of the problems it solves, I don't need it. Spring
>> already has "Spring Data MongoDB" and "Spring Data Solr" projects, and I
>> think there should be a "Spring Data JCR" project also, that is basically
>> JackrabbitOak packaged similarly to how I do it in meta64.com. That is,
>> basically Oak dependencies, with a thin layer of spring beans exposing it,
>> and a bit of AOP for session management, etc.
>>
>> ​My apologies if this is an inappropriate forum for such a discussion.​
>>
>> Best regards,
>> Clay Ferguson
>> wclayf@gmail.com
>>
>>
>> On Tue, Aug 4, 2015 at 9:04 AM, Robert Munteanu <ro...@lmn.ro> wrote:
>>
>>> On Mon, Aug 3, 2015 at 8:14 AM, Clay Ferguson <wc...@gmail.com> 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 a totally prepackaged way of doing stuff is what most
>>> developers want
>>> > these days. There are just too many moving parts in most large
>>> systems, so
>>> > people need "prepackaged" configurations that just work right out of
>>> the
>>> > box, at least for some minimal set of the most common usage patterns.
>>> I'm
>>> > not sure if there's any plans to integrate into SpringBoot, but IMO
>>> that
>>> > would be a hugely important thing for the industry if Oak was part of
>>> > SpringBoot stack.
>>>
>>> I'm not an Oak developer, so don't take this as any sort of official
>>> statement, but the way I understand it the Jackrabbit project only
>>> provides the Oak code / binaries ; packaging it in suitable formats
>>> for development / deployment is left to packagers / other projects.
>>>
>>> One such example is Apache Sling ( https://sling.apache.org ), a
>>> framework built on top of JCR, REST and OSGi. But if you're
>>> well-versed in Spring and convinced that you should switch to OSGi it
>>> won't help you much. In that case "someone" ( it's always someone else
>>> :-) ) should provide that integration.
>>>
>>> Cheers,
>>>
>>> Robert
>>> --
>>> Sent from my (old) compute
>>>
>>
>>

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Justin Edelson <ju...@justinedelson.com>]

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 <wc...@gmail.com> 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 the world, is because it
> can make completely incompatible set of things be able to run together. For
> example, if I have component A that requires version B of of some specific
> class but perhaps B is using an older component C than the version of C
> that A is using internally...then a single classpath cannot ever work. You
> must have an environment which gives each component it's own "world (i.e.
> separate classpath)" or environment to run in.
>
> What SpringBoot is all about, on the other hand, is saying let's design a
> single set of dependencies (Technology Stack) that are all *known* to work
> together (single classloader) on the same versions of all dependencies in
> the chain, and eliminate the version conflicting before it starts, thus
> eliminating *one of* the problems OSGi solves. So OSGi is great, but unless
> I run directly into one of the problems it solves, I don't need it. Spring
> already has "Spring Data MongoDB" and "Spring Data Solr" projects, and I
> think there should be a "Spring Data JCR" project also, that is basically
> JackrabbitOak packaged similarly to how I do it in meta64.com. That is,
> basically Oak dependencies, with a thin layer of spring beans exposing it,
> and a bit of AOP for session management, etc.
>
> ​My apologies if this is an inappropriate forum for such a discussion.​
>
> Best regards,
> Clay Ferguson
> wclayf@gmail.com
>
>
> On Tue, Aug 4, 2015 at 9:04 AM, Robert Munteanu <ro...@lmn.ro> wrote:
>
>> On Mon, Aug 3, 2015 at 8:14 AM, Clay Ferguson <wc...@gmail.com> 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 a totally prepackaged way of doing stuff is what most developers
>> want
>> > these days. There are just too many moving parts in most large systems,
>> so
>> > people need "prepackaged" configurations that just work right out of the
>> > box, at least for some minimal set of the most common usage patterns.
>> I'm
>> > not sure if there's any plans to integrate into SpringBoot, but IMO that
>> > would be a hugely important thing for the industry if Oak was part of
>> > SpringBoot stack.
>>
>> I'm not an Oak developer, so don't take this as any sort of official
>> statement, but the way I understand it the Jackrabbit project only
>> provides the Oak code / binaries ; packaging it in suitable formats
>> for development / deployment is left to packagers / other projects.
>>
>> One such example is Apache Sling ( https://sling.apache.org ), a
>> framework built on top of JCR, REST and OSGi. But if you're
>> well-versed in Spring and convinced that you should switch to OSGi it
>> won't help you much. In that case "someone" ( it's always someone else
>> :-) ) should provide that integration.
>>
>> Cheers,
>>
>> Robert
>> --
>> Sent from my (old) compute
>>
>
>

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Clay Ferguson <wc...@gmail.com>]

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
wclayf@gmail.com


On Thu, Aug 6, 2015 at 9:12 AM, Torgeir Veimo <to...@gmail.com>
wrote:

> On 5 August 2015 at 18:43, Bertrand Delacretaz <bd...@apache.org>
> 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
>

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Torgeir Veimo <to...@gmail.com>]

On 5 August 2015 at 18:43, Bertrand Delacretaz <bd...@apache.org> 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

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Aug 4, 2015 at 5:08 PM, Clay Ferguson <wc...@gmail.com> 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 way of assembling very modular and dynamic
systems. The tooling and examples might not be as sexy as other
similar frameworks, but for the kind of industrial strength stuff that
Sling is aimed at OSGi works extremely well for us.

And on top of that, as you say, when one needs to integrate
legacy/ugly code OSGi can be a lifesaver.

-Bertrand

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Robert Munteanu <ro...@apache.org>]

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 the world, is 
> because it can make completely incompatible set of things be able to 
> run together. For example, if I have component A that requires 
> version B of of some specific class but perhaps B is using an older 
> component C than the version of C that A is using internally...then a 
> single classpath cannot ever work. You must have an environment which 
> gives each component it's own "world (i.e. separate classpath)" or 
> environment to run in. 
> 
> What SpringBoot is all about, on the other hand, is saying let's 
> design a single set of dependencies (Technology Stack) that are all 
> *known* to work together (single classloader) on the same versions of 
> all dependencies in the chain, and eliminate the version conflicting 
> before it starts, thus eliminating *one of* the problems OSGi solves. 
> So OSGi is great, but unless I run directly into one of the problems 
> it solves, I don't need it. Spring already has "Spring Data MongoDB" 
> and "Spring Data Solr" projects, and I think there should be a 
> "Spring Data JCR" project also, that is basically JackrabbitOak 
> packaged similarly to how I do it in meta64.com. That is, basically 
> Oak dependencies, with a thin layer of spring beans exposing it, and 
> a bit of AOP for session management, etc.

Sounds pretty much like something we can 'debate' over a beer, after
having settled whether vim or emacs is superior. 

Just kidding, vim is clearly the winner here ;-)

Cheers,

Robert

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Clay Ferguson <wc...@gmail.com>]

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 to run together. For
example, if I have component A that requires version B of of some specific
class but perhaps B is using an older component C than the version of C
that A is using internally...then a single classpath cannot ever work. You
must have an environment which gives each component it's own "world (i.e.
separate classpath)" or environment to run in.

What SpringBoot is all about, on the other hand, is saying let's design a
single set of dependencies (Technology Stack) that are all *known* to work
together (single classloader) on the same versions of all dependencies in
the chain, and eliminate the version conflicting before it starts, thus
eliminating *one of* the problems OSGi solves. So OSGi is great, but unless
I run directly into one of the problems it solves, I don't need it. Spring
already has "Spring Data MongoDB" and "Spring Data Solr" projects, and I
think there should be a "Spring Data JCR" project also, that is basically
JackrabbitOak packaged similarly to how I do it in meta64.com. That is,
basically Oak dependencies, with a thin layer of spring beans exposing it,
and a bit of AOP for session management, etc.

​My apologies if this is an inappropriate forum for such a discussion.​

Best regards,
Clay Ferguson
wclayf@gmail.com


On Tue, Aug 4, 2015 at 9:04 AM, Robert Munteanu <ro...@lmn.ro> wrote:

> On Mon, Aug 3, 2015 at 8:14 AM, Clay Ferguson <wc...@gmail.com> 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 a totally prepackaged way of doing stuff is what most developers
> want
> > these days. There are just too many moving parts in most large systems,
> so
> > people need "prepackaged" configurations that just work right out of the
> > box, at least for some minimal set of the most common usage patterns. I'm
> > not sure if there's any plans to integrate into SpringBoot, but IMO that
> > would be a hugely important thing for the industry if Oak was part of
> > SpringBoot stack.
>
> I'm not an Oak developer, so don't take this as any sort of official
> statement, but the way I understand it the Jackrabbit project only
> provides the Oak code / binaries ; packaging it in suitable formats
> for development / deployment is left to packagers / other projects.
>
> One such example is Apache Sling ( https://sling.apache.org ), a
> framework built on top of JCR, REST and OSGi. But if you're
> well-versed in Spring and convinced that you should switch to OSGi it
> won't help you much. In that case "someone" ( it's always someone else
> :-) ) should provide that integration.
>
> Cheers,
>
> Robert
> --
> Sent from my (old) compute
>

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Robert Munteanu <ro...@lmn.ro>]

On Mon, Aug 3, 2015 at 8:14 AM, Clay Ferguson <wc...@gmail.com> 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 a totally prepackaged way of doing stuff is what most developers want
> these days. There are just too many moving parts in most large systems, so
> people need "prepackaged" configurations that just work right out of the
> box, at least for some minimal set of the most common usage patterns. I'm
> not sure if there's any plans to integrate into SpringBoot, but IMO that
> would be a hugely important thing for the industry if Oak was part of
> SpringBoot stack.

I'm not an Oak developer, so don't take this as any sort of official
statement, but the way I understand it the Jackrabbit project only
provides the Oak code / binaries ; packaging it in suitable formats
for development / deployment is left to packagers / other projects.

One such example is Apache Sling ( https://sling.apache.org ), a
framework built on top of JCR, REST and OSGi. But if you're
well-versed in Spring and convinced that you should switch to OSGi it
won't help you much. In that case "someone" ( it's always someone else
:-) ) should provide that integration.

Cheers,

Robert
-- 
Sent from my (old) compute

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Clay Ferguson <wc...@gmail.com>]

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 developers
want these days. There are just too many moving parts in most large
systems, so people need "prepackaged" configurations that just work right
out of the box, at least for some minimal set of the most common usage
patterns. I'm not sure if there's any plans to integrate into SpringBoot,
but IMO that would be a hugely important thing for the industry if Oak was
part of SpringBoot stack.

Best regards,
Clay Ferguson
wclayf@gmail.com


On Sun, Aug 2, 2015 at 11:52 PM, Chetan Mehrotra <ch...@gmail.com>
wrote:

> 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 config in non OSGi env like say war deployment. Need to get some
> time to finish it and adopt the standalone web example to use that
>
> Chetan Mehrotra
> [1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-pojosr
>
>
> On Sun, Aug 2, 2015 at 11:26 PM, Clay Ferguson <wc...@gmail.com> wrote:
> > 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 sharing my
> > example:
> >
> > This code creates a Full Text Search on jcr:content, and an sorting
> > capability on jcr:lastModified:
> >
> >
> https://github.com/Clay-Ferguson/meta64/blob/master/src/main/java/com/meta64/mobile/repo/OakRepository.java
> >
> > I also just updated meta64 project to be using the 1.0.18 branch of the
> > Jackrabbit code, so it's all up to date stuff. I would highly recommend
> > adding this or a similar example right onto the Lucene page of the Oak
> docs,
> > because what I'm doing is exactly what everyone else wants, and the
> > documentation itself is just completely confusing and mind boggling
> without
> > a real example.
> >
> > Cheers, and happy jackrabbiting.
> >
> > Best regards,
> > Clay Ferguson
> > wclayf@gmail.com
> > meta64.com
> >
>

Re: JCR + MongoDb + Lucene Holy Grail Finally Found

[Chetan Mehrotra <ch...@gmail.com>]

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 config in non OSGi env like say war deployment. Need to get some
time to finish it and adopt the standalone web example to use that

Chetan Mehrotra
[1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-pojosr


On Sun, Aug 2, 2015 at 11:26 PM, Clay Ferguson <wc...@gmail.com> wrote:
> 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 sharing my
> example:
>
> This code creates a Full Text Search on jcr:content, and an sorting
> capability on jcr:lastModified:
>
> https://github.com/Clay-Ferguson/meta64/blob/master/src/main/java/com/meta64/mobile/repo/OakRepository.java
>
> I also just updated meta64 project to be using the 1.0.18 branch of the
> Jackrabbit code, so it's all up to date stuff. I would highly recommend
> adding this or a similar example right onto the Lucene page of the Oak docs,
> because what I'm doing is exactly what everyone else wants, and the
> documentation itself is just completely confusing and mind boggling without
> a real example.
>
> Cheers, and happy jackrabbiting.
>
> Best regards,
> Clay Ferguson
> wclayf@gmail.com
> meta64.com
>