cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Sat, 03 Dec 2005 04:54:15 GMT
Sylvain Wallez wrote:
> Tell me your thoughts. Am I completely off-track, or do you also want to 
> build this great new thing?
Hmm, I don't know - I think your ideas make mostly sense (we already
discussed some of them in the past), but for me these are technical
details (I don't say that they are not important). But I think, we need
a vision for 3.0 - what do we want to achieve?

Now, most of the alternatives to Cocoon have one thing in common: they
are easy too learn and you can start quickly (and most of them have the
"start quick and fail later" problem but that's another story). Whereas
if you want to use Cocoon, you can't start right away. There is so much
to learn, so many different files you have to write/adjust.

Why do managers love Struts or JSF? It's a "standard" but even more
important, they have tools. Fancy tools sell your product, that's the
bitter truth. And I have the feeling, that products, that don't have
tools but are "just cool", will not be used anymore (it's just a feeling).

I think from a technological point of view, Cocoon is still at the top,
we can easily support ajax, we could integrate Spring or spring flow if
required etc. But I think, developing with Cocoon needs to be more
productive than it is today.

Just an example, CForms is a great framework, it offers everything you
need - but providing a simple form for editing a bean requires several
different files to be created.

In the end it comes down to the following two things: we need a good
documentation and it must be productive to develop with Cocoon.

I'm not a believer of all these "too-much-magic" frameworks or
generating stuff. So I think using Cocoon should be simpler and we need
tools. Why don't we have tools? For example, we don't have a sitemap
editor, we even don't have a simple tool that can validate a sitemap or
an xconf etc. Not to mention that developing with Cocoon currently
requires to define your own build system.

For some of our problems, we already have answers, being it using Maven,
implementing real blocks, adding this new feature here and there. And we
are very good in agreeing on these things, but we are not that good in
actually doing them :(

So, yes, I think we need some radical changes for 3.0 - but I fail to
see what these should be. There are two things clear for me: developing
with Cocoon must get easier, and we'll get this with Maven - and we need
much better docs. (Of course, the docs have heavily improved in the last
months but many things are simply not documented at all yet).

And to give some more meat to discuss (or rant about) as I will be
offline for the next ten days: I'm still in the "we don't need OSGi"
camp (as some of us are here), as I still believe that it adds to much
complexity. But as others (who I trust) believe in this and as I don't
have time to work on this, the only way to progress is to not block
those who have time to do something. But I come more and more to the
conclusion that we simply should use Spring as the base framework and
build some class loading stuff on top of it (which we already have with
the sitemap classloaders). That would be a simple but sufficient solution.

For new (portal) projects, I think it makes sense to use Cocoon as the
portal framework, but to use JSF etc to build the portals. Sad, but
true. Developing with Cocoon is not productive, so we need to change
this :) Ok, I'll now go offline for some time and come back when the
waves (hopefully) have cleared...

Carsten Ziegeler - Open Source Group, S&N AG

View raw message