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 17:03:59 GMT
Sylvain Wallez wrote:
> Tools are actually a way to hide complexity.

>  What if the tool you need
> is a plain Java IDE with a JavaScript plugin because all you have is a 
> pipeline API and Flowscript/Javaflow?
Hmm, and why not having a graphical pipeline builder on top? I've
recently seen some vendor products doing exactly that - they are not
using Cocoon underneath, but have a similar product and really nice tools.

> Sorry, but saying that a build tool is the solution to our problems is 
> burying you head in the sand, as it's just trying to automate the 
> management of complexity.
It's not the solution for all of our problems, but it helps in being
productive. First time Cocoon users always ask "Ok, I've downloaded
Cocoon and now what? How do I manage my project?" And then later on "How
do I update my Cocoon version?" And so on. Automatic build management is
imho a must for every project (it enables continuous integration etc.)

> And IMO we don't even need that. As was Gianugo said later, the whole 
> blocks stuff, if you think about it, is just about adding an additional 
> level of complexity in the hope to hide the current one. Just like the 
> sophisticated build tool, actually.
Hehe, good try :) Now, actually, this is one of the points where I
currently disagree. But I'm very happy to be profen wrong. Adding
another level of complexity in the hope to hide the current one, seems a
little bit strange to me whereas we currently don't have a build
solution at all - I mean a solution for building projects that use
Cocoon. But anyways, let's see what the future brings :)


Carsten Ziegeler - Open Source Group, S&N AG

View raw message