Hi Rick,

Oak is JackRabbit 3.0.  My understanding is that it is a revamping / 
modernization but the purpose / goal remains unchanged.  You’ve probably seen 
this, but you can read more here<http://jackrabbit.apache.org/oak/>.


Our use of JackRabbit started around 2.2 / 2.4 and we are currently using 2.8.  
The transitions between 2.x version have been fairly easy; I expect the 
transition to 3.0 to be more involved, but we have not started our investigated 
yet (it’s scheduled for the next sprint).

We have traditionally use SQL databases for backend storage, but do have a 
major project using JackRabbit.  We found these features compelling:

* Strong hierarchy support - the data for this particular project inherently 
hierarchical.
* Dynamic properties
* Ability to store file data at any point in the hierarchy

We were also drawn to the features that come out of the box with JackRabbit: 
user & security model, versioning, etc.  We run JackRabbit embedded within each 
process (web app & backend processes); the clustering configuration took some 
effort to get right (we are still tweaking it), but we have been successful.  
My impression is that many people are using JackRabbit for projects where the 
number of reads vastly exceeds the number writes (sounds like that might be 
true for you also), but, for our project, reads & writes are on a close[er] 
scale.  Overall we’ve been happy with JackRabbit.


If you have been using a file system, I think a JCR would be a good match and 
give you additional control & features.  If I were considering a new project 
now, I would look at Oak / JackRabbit 3.0; there’s always concerns about being 
close the leading edge, but that's where I would start.


Background: I’m a JackRabbit user, not contributor; I have, on occasion, 
explored / debugged through the JackRabbit sources but am not an expert on its 
inner workings.

The folks working on Oak would be better able to describe its intent.


I hope that is helpful.

Morrell Jacobs
Chief Software Architect
MEI
610 Old York Road, Suite 250
Jenkintown, PA 19046
Phone: 215-886-5662, ext. 252
Fax: 215-886-5681
http://www.maned.com
E-mail: [email protected]<mailto:[email protected]>
AOL IM: MorrellMEI

Have you seen Nervous Pixel, MEI's creative services division?
www.nervouspixel.com<http://www.nervouspixel.com/>



On Nov 5, 2014, at 9:14 AM, Herrick, Rick 
<[email protected]<mailto:[email protected]>> wrote:

We're in the process of working on an archive management system for our medical 
imaging data platform (XNAT, http://www.xnat.org). Currently we just manage 
files on the hosting file system, with all the issues that implies. We've been 
considering using Jackrabbit to manage all of the data resources (MRI, CT, PET 
and similar imaging data, synthetic data from processing and analysis 
pipelines, research subject data, etc.), but we have a few concerns.

There doesn't seem to have been too much activity on this list, most of the 
articles on the Jackrabbit articles page are from 2011 and earlier, and most of 
the Jackrabbit news is actually about Oak.

So is Jackrabbit still an on-going and supported platform? Should we be looking 
at Oak instead? Basically we don't want to embark on a full-blown development 
effort on something that may not be maintained. Or is just that, because this 
is a back-end technology, there's just not that much traffic and that's 
actually a GOOD thing (i.e. it's basically done and it works and no one 
complains)?

Any thoughts on this would be very helpful and greatly appreciated. Thanks!

--
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
(314) 740-5961

________________________________

The material in this message is private and may contain Protected Healthcare 
Information (PHI). If you are not the intended recipient, be advised that any 
unauthorized use, disclosure, copying or the taking of any action in reliance 
on the contents of this information is strictly prohibited. If you have 
received this email in error, please immediately notify the sender via 
telephone or return mail.

Reply via email to