Kind of, what I'm after specifically is either CMS' built on top of Jackrabbit 
or ones that provide a JCR version 2 interface (depending on what route we end 
up taking, OFBiz with embedded Jackrabbit or OFBiz using the JCR API to access 
any compliant repository).

http://en.wikipedia.org/wiki/Content_repository_API_for_Java  (this page has a 
link to http://www.jcrdev.com/jcrdev.html which I didn't know existed but looks 
useful)
http://en.wikipedia.org/wiki/Apache_Jackrabbit

Regards
Scott

On 21/06/2010, at 8:19 PM, Sam Hamilton wrote:

> Wikipedia to the rescue -
> http://en.wikipedia.org/wiki/List_of_content_management_systems#Java_2
> 
> Cheers
> Sam
> 
> On 21/06/2010 15:42, Scott Gray wrote:
>> On 21/06/2010, at 7:33 PM, Jacques Le Roux wrote:
>> 
>>> Hi Scott,
>>> 
>>> Interesting, BTW why did you pick Hippo, did you compare with open 
>>> competitors (using JackRabbit underneath of course) ?
>> 
>> Jacques, that is a very good question :-)
>> I never actually considered that there were others, it was the first I 
>> stumbled across.  Oops, I should probably go and check.
>> 
>>> Thanks
>>> 
>>> Jacques
>>> 
>>> Scott Gray wrote:
>>>> You're making a pretty big assumption that CMS apps are interchangeable so 
>>>> long as the repo is jackrabbit.  Jackrabbit (or more
>>>> specifically the JCR) provides nothing more than a standard interface for 
>>>> querying and interacting with content nodes, it does
>>>> nothing to define or enforce a specific node/hierarchy structure.  From 
>>>> what I've seen so far, the CMS defines the structure
>>>> which would preclude OFBiz from being able to do so if we want to be able 
>>>> to use anything other than our own hand rolled CMS.   It's a bit like 
>>>> suggesting that because we have SQL and JDBC you can therefore sit any 
>>>> application on top of any database, which
>>>> is really only true for the most generic of applications (i.e. a database 
>>>> browser).  You could probably interchangeably use any
>>>> number of generic repository browsers to access jackrabbit but as soon as 
>>>> you push to a much higher level than that you are going
>>>> to run into problems.   I guess it could be possible to have some sort of 
>>>> translation layer in which you map your CMS's content structure into 
>>>> something
>>>> that OFBiz can understand.  For example telling OFBiz that all product 
>>>> names can be accessed via
>>>> "/content/products/${productId}/productName" but that assumes product name 
>>>> is a node rather than a node attribute like
>>>> "/content/products/${product}['productName']" and I'm not sure what 
>>>> implications that might carry along with it because OFBiz
>>>> might need to deal with an attribute differently than it might a node.    
>>>> In short, I really have very little idea of what I'm talking about.  But 
>>>> if we all wait for someone else to figure this stuff out
>>>> then I fear we may end up waiting quite a while. I guess ideally we would 
>>>> have a branch that contains a jackrabbit client component, a Hippo CMS 
>>>> component and another CMS app
>>>> component.  We could then use them to experiment with approaches for OFBiz 
>>>> to interact with each CMS's repository structure in a
>>>> generic manner.  Regards
>>>> Scott
>>>> On 21/06/2010, at 3:21 AM, Adrian Crum wrote:
>>>>> Actually, no - we don't need to build a CMS application. We can use an 
>>>>> existing one. A bare-bones content repository is what we
>>>>> want. The concept proposed so far (as far as I can tell) is to find a way 
>>>>> to integrate Jackrabbit into OFBiz, then a user can select
>>>>> any CMS they want to run on top of it. -Adrian
>>>>> --- On Sat, 6/19/10, Scott Gray <[email protected]> wrote:
>>>>>> From: Scott Gray <[email protected]>
>>>>>> Subject: Re: Hippo CMS
>>>>>> To: [email protected]
>>>>>> Date: Saturday, June 19, 2010, 4:27 PM
>>>>>> The thing to remember is that
>>>>>> Jackrabbit is nothing more than a content repository, like a
>>>>>> database for your content.  If we go the route of using
>>>>>> a raw repository then we have to build a CMS application to
>>>>>> sit on top of it.
>>>>>> What I am proposing is to use the work of others rather
>>>>>> than build something new from the ground up.  I don't
>>>>>> know about you but designing content management systems
>>>>>> isn't exactly my area of expertise.  Last time I
>>>>>> checked you can't even buy a book about using the JCR.
>>>>>> Regards
>>>>>> Scott
>>>>>> On 20/06/2010, at 1:42 AM, Adrian Crum wrote:
>>>>>>> I would be interested in helping out with integrating
>>>>>> Jackrabbit with OFBiz.
>>>>>>> -Adrian
>>>>>>> --- On Fri, 6/18/10, Scott Gray <[email protected]>
>>>>>> wrote:
>>>>>>>> From: Scott Gray <[email protected]>
>>>>>>>> Subject: Hippo CMS
>>>>>>>> To: [email protected]
>>>>>>>> Date: Friday, June 18, 2010, 6:57 PM
>>>>>>>> Anybody using or considered using
>>>>>>>> Hippo CMS (onehippo.org) in conjunction with
>>>>>> OFBiz?
>>>>>>>> - Apache Licensed
>>>>>>>> - Uses Jackrabbit as its repository
>>>>>>>> - Supports Versioning, Internationalization,
>>>>>> Publishing
>>>>>>>> Workflows and more
>>>>>>>> We could start out by using Hippo's UI to manage
>>>>>> content
>>>>>>>> and retrieve it for display within OFBiz using the
>>>>>> JCR
>>>>>>>> API.  As the various document types needed by
>>>>>> the OFBiz
>>>>>>>> base applications begin to take shape we could
>>>>>> look at ways
>>>>>>>> to allow the content to be modified directly from
>>>>>> within
>>>>>>>> OFBiz (once again using the JCR API).
>>>>>>>> Any thoughts, alternatives, ideas or whatever
>>>>>> would be
>>>>>>>> appreciated.  I'm considering working on a
>>>>>> POC in my
>>>>>>>> spare time, not sure how long that might take at
>>>>>> this
>>>>>>>> stage.  I already have a copy of Hippo
>>>>>> running inside
>>>>>>>> OFBiz but that was just a matter of expanding
>>>>>> their WAR
>>>>>>>> distribution and wrapping it in a component, next
>>>>>> step would
>>>>>>>> be gaining access to the repo from OFBiz code.
>>>>>>>> Thanks
>>>>>>>> Scott
>>>>>>>> HotWax Media
>>>>>>>> http://www.hotwaxmedia.com
>>> 
>> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to