>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 portals.apache.org (and perhaps one day cms.apache.org).
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 + etc...
Products compete against products. Cooptition rules apply at the Framework level.
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.
Cheers, St�phane
