Concerning the JCR support, we want to maximize the abstraction on the repository. JCR is certainly a very nice spec but it is too low level API. I can't image to use the JCR object model (Node, Item & Property) in some portlets, jsp pages, ... I prefer to use CMS objects like Folder, Forum, Thread, News, Article, ...
you mean similar to Zope?
... and jumping on this idea, yes, I personally think it would great to have some kind of shared Visual Content Explorer (� la CRX - http://jsr170tools.day.com/crx/login.jsp) + Visual JCR170 Admin Center initiative on top of Jackrabbit. Quite similar to the Zope Content Management Framework.
Each CMS (including Jahia ;-) ) will need something like that on top of Jackrabbit. For example creating definitions on top of Jackrabbit is quite(too) complex for a CMS user/integrator and you need some kind of abstract management layer in-between. So we have the choice to try to centralize these "back-end" tools (in opposite to the front-end CMS views, navigations, edition mechanisms, etc.. which are of course specifc to each CMS/Portal system) or to each independently reinvent the wheel...
Zope has a centralized Core system (= Jackrabbit), a shared Content Management Framework (= Apache ???) and several "finished" CMS products such as Plone, Icoya, Silva,...(= Lenya, Graffito, Magnolia, Jahia,...). Why not doing the same and taking the JSR170 opportunity to do in Java what Zope already did in Python?
Anyway, it is a common question for the ASF. Why Trapestry, Struts, Turbine, Cocoon. Is it not the same stuff to make web apps :-) ?
Well, I think in most cases there is not just one way of doing things and Apache allows
various ways and I think this is good. It might be seen as a waste of resources, but
I think it's more a question of finding the right balance.
Yes but this also creates much confusion for end-users (cf. the recent OSCOM thread: http://oscom.org/get-involved/mailing-lists/general/2005-March/000470.html ). Then is the ASF only a Java SourceForge which host all java based initatives. I do not think so. There are not 10 different Apache httpd projects. Apache is about providing good, well maintained back-end librarires each of them powered by a strong community. So there are already Slide, Lenya, Jackrabbit and now Graffito... Jackrabbit still has issues gathering a community large enough to exit the incubator status. Do you think Graffito has then a real chance? So perhaps time to try to consolidate a bit at least for the back-end tools, no?
Cheers, St�phane
Thanks
Michi
Regards, Christophe
Here is the Graffito architecture :
------------------------------------------------------------
Graffito clients :
JSR 168 Portlets - Web apps - EJB's - Spring components - ...
-------------------------------------------------------------
^ ^
| |
| |
============================================================= Graffito Container (Spring)
------------------------------------------------------------- 1. Application domain components GraffitoForum GraffitoNewsManagement
GraffitoBrowser
GraffitoKM CustomApplication GraffitoDocManagement
-----------------------------------------------------------------------
2. Services
Security Workflow Model Search Version ----------------------------------------------------------------------
3. Persistence Service
(= virtual content tree which groups together different kind of content store)
There is a pluging for each type of content repository
We have a "propriatary store" based on OJB and we want to build one for JCR
OJB plugin Webdav plugin JCR plugin Propriatary plugin
============================================================
--------- --------- --------
Repo1 Repo 2 Repo3
-------- --------- -------
-- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED] [EMAIL PROTECTED]
- -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- -
www.jahia.org : A Collaborative Source CMS and Portal Server
