cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [proposal] cocoonstuff.org
Date Thu, 28 Jul 2011 13:09:43 GMT
Le 21/07/11 20:54, Reinhard Pötz a écrit :

<snip/>

> Nevertheless C3 already counts more than 20 subdirectories which is 
> discouraging for people that want to get familiar with the code base. 
> Especially if you don't need all the webapp/REST stuff you only need 
> cocoon-pipeline, cocoon-sax, parent and maybe cocoon-optional.
> One could say that this problem can be solved with good documentation 
> but the psychological barrier doesn't go away.

Hmm... needing additional documentation is often the sign of some sort 
of problem. In this case, we may simply have too many modules. Why don't 
we have a "cocoon-core" module, so that people can know where to look at 
to understand what Cocoon is about? And this core module should not only 
be the cocoon-pipeline module, but should also include cocoon-util (3 
classes!), cocoon-sax, cocoon-sitemap, cocoon-controller (3 classes 
again) and even cocoon-stax (Stax is provided in JDK 1.6).

Also, along with providing more meat in the core, let's be opinionated 
and clearly say what Cocoon is about. For 2.2, the website says "Apache 
Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built 
around the concepts of separation of concerns and component-based 
development."

Er... and what does this mean for a newcomer, particularly when Spring 
already has this huge amount of components and whose large number of 
interfaces and abstract classes could well be confused with "separation 
of concerns" ?

What about a probably restrictive but clearer "Cocoon is a versatile 
pipeline processing engine, particularly suited for XML processing and 
multi-format document publication, but also capable of processing binary 
content such as images. It provides integration modules with popular 
frameworks like Spring, Wicket and JAX-RS"?

With a bigger core and a clear tag line, we end up with a project that 
has 3 times less modules and where additional modules have a clear goal 
of integrating with a 3rd party library/framework (or providing a very 
specific feature, which often means also a 3rd party library). And more 
importantly, we have a core module that can actually *do* something and 
is not an almost empty shell of abstact concepts like cocoon-pipeline is.

Sorry for this rant, but Cocoon has 2.x has grown into a toolbox for its 
committers (and I take my share in this), becoming more and more complex 
and abstract, being a different thing for each of its developers, and 
has lost its ability to be understood by newcomers. I think learning 
from this is particularly important if we want to rebuild a vibrant 
community around Cocoon 3.x

Sylvain

-- 
Sylvain Wallez - http://bluxte.net


Mime
View raw message