incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From St├ęphane Croisier <>
Subject RE: Why not using Lenya
Date Fri, 18 Mar 2005 13:40:52 GMT
At 13:15 18/03/2005, you wrote:
> >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?
>Is the JCR Spec is mature enough for doing that ? Who will follow the JCR 
>spec ? it is too early to gives an anwser to those questions. It dangerous 
>to base everything on JCR.

And is it better to reinvent the wheel? The JCR will perhaps be a 
success... or not. It does not really matter. In all cases, it looks like 
the Jackrabbit implementation is nice and well coded. So at least you avoid 
recoding the core kernel of a CMS (and perhaps you do not need to use all 
the features provided by Jackrabbit)...

Furthermore if, at least Day, Lenya, Magnolia and Jahia integrates 
Jackrabbit into their own product offering, this should lead to a quite 
well maintained kernel library (ok, I agree you need to like Swiss citizens 
as all these initatives are Swiss ;-) ... I always wanted to know why there 
are so much interest in Switzerland for CMS and not in other countries ;-) )

>Graffito is not a finished CMS product. It can be use like this but this 
>is not mandatory.It is really a component/framework based solution.
>If I understand your point of view, Graffito can be the shared management 
>framework and we will see later if this kind of initiative it interesting 
>for the Java/open source community.
>That's the same for Jetspeed 2, almost all Jetspeed services can be 
>running outside j2. Eg. : I can use the J2 security stuff with Graffito 
>outside J2.

I think that the Zope community has a good point. They clearly separated 
the core kernel (in the Java case the JSR168 or JSR170 RI), the Framework 
(the CMS or the Portal Framework) and the "products" (ready to use GUIs, 
finished, easy to install, tested, prepackaged with functional 
templates/portlets, with possible commercial support, etc...).

What I mean is that currently there is not this man-in-the-middle in (and perhaps one day

Michi wrote:
>The idea of Lenya is to offer a CM Framework by enhancing Cocoon by CM
>componets, but also a CMS "nearly out of the box"

This is exactly what I mean. You have a CM Framework + a CMS "product" 
nearly out of the box ... but in the same project.
Same is true for Pluto/Jetspeed.

In the middle/long run, I do not think this will ease code reuse or code 
sharing among "products". As there is no defined framework project, the 
final product will always influence the choices for the entire framework. 
This may then creates conflicts with other "products" relying on the same 
back-end framework libraries which, because of their commercial or other 
uncompliant licenses status, can of course not "compete" in terme of number 
of committers as they will not be involved on the ready to use product side 
of the Apache offering.

Concretely, Jahia now integrates the J2 Framework (that I distinguish from 
the J2 final "product"). I think this is a great news as this will 
automatically bring 100+ customers including several Fortune 1000 ones and 
should give aboost to the J2 market shares ;-) . But as the J2 Framework 
coexist with the "product" in the same Apache project, the J2 product 
influences (or risks to influence) a bit too much decisions taken for the 
Framework. I do not think this is good. The goal is really to have as many 
commercial or free offerings on top of J2 (and/or a common shared CMS 
framework). All these products will then need to "fight" on the same terms 
at the Framework level.

So that's why I think the Zope organisational structure is not so bad. It 
clearly allow ressources gathering on the Portal or CMS Frameworks layer 
and let up to other free or commercial projects to make the glue + GUI  + 

Products compete against products. Cooptition rules apply at the Framework 

So to come back to more concrete things regarding Graffito, IMHO it would 
be great to have this CMS Framework layer project launched on top of 
Jackrabbit. Call it Graffito or Lenya CMS Framework or Jackrabbit 
Framework, I do not care.


View raw message