cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
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.
Yupp.

>  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

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message