incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wechner <>
Subject Re: Why not using Lenya
Date Thu, 17 Mar 2005 22:47:27 GMT
LOMBART Christophe wrote:

>Hi St├ęphane,
>Well, this is only my point of view and I'm not the Leyna expert so maybe some     arguments
are not correct. Hope to see some Leyna experts in this thread.
>Yes, we can add this kind of info in a FAQ.
>Here is my arguments :
>* Leyna is build on Cocoon. Graffito is build on simple POJO components which can run
anywhere. We are supporting by default Spring and PicoContainer seems to be not a problem.
Is it possible to run Leyna outside Cocoon ? 

well, Lenya is based on Cocoon ;-)

>* Leyna is focusing on CMS. We want to provide (in long term) more features (DM,  Forums,
...) . See the architecture diagram below. It should be nice to see in Graffito some  predefined
portal applications like News management, forum, document manager, page editor, ...

I guess Lenya has similar goals, but uses a different approach

>* Graffito will be the default CMS solution for Jetspeed 2. Cocoon & Jetspeed  are
not really compatible. Furthermore, it should be nice to have a CMS implementation for the
Jetspeed 2 page manager - Is it possible if we will use Leyna ? 

I really don't know, because I am not familiar with Jetspeed

>* We are building some JSR-168 portlets. Is there desired by the Leyna team ? 

yes, I think so :-) Cocoon is supporting JSR-168 and and it makes sense
to integrate and support the Portal functionality into Lenya

>I'm agree there are certainly common point between both products like workflow,  JCR support,
... . If Leyna team is agree, why not to create somethink like a CMS common area ? 

that would certainly make sense, whereas it needs people to understand 
both projects.

OSCOM is trying to establish shared projects between the various Open 
Source CMS projects (not just Apache and not just Java ;-) and it seems 
to me that Kupu
and BXE have succeeded, but it takes time and patience, because people 
get to
know each other, etc.

>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?

> If a new spec is comming later, we want to minimize the impact on the application domain.
That's why the JCR integration should be made with a simple content repository plugin. It
is make sense for the Leyna team and also for you ? I think it is important to debate on that

For the moment Lenya is integrating Jackrabbit for documents, but yes it 
would make
sense to discuss it and you might want to ask this on the Jackrabbit 
mailing list ;-)

>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.



>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                          

View raw message