cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Date Tue, 06 Aug 2002 15:39:38 GMT
Carsten Ziegeler wrote:

>People,
>
>it's really interesting and I must confess also amuzing to follow
>such a thread like this.
>
>It started with a list of problems we currently have and a 
>proposal for reorganizing the project structure.
>And it didn't take long until several come up and say, "Hey,
>the solution is simple: we make Cocoon 3/4 or even Cocoon XP."
>
>How will we ever get people/companies to use Cocoon if we
>change (or refactor) the core every five months? Is this
>refactoring the only solution? Is it the best solution?
>
>You all should now that even changing a package name is a
>real PITA for updating an already running system.
>
>So, *if* we vote on refactoring or starting a new Cocoon
>major version, I'm definitly -1 on this. 
>  
>

Same for me : -1

I experienced recently a customer which preferred JSP/Struts to Cocoon. 
Cocoon seemed really a nice thing to them, allowing their app to be more 
cleanly built than with Struts, but they were afraid of both its 
stability and the important learning curve, even if my company was able 
to provide support and consulting.

So if we want to be able to sell cocoon-based solutions or see large 
companies adopt Cocoon we *need* this stability.

Something we didn't talk of up to now is testing : subsitemap handling 
by the treeprocessor is broken in the 2.0.3 release because of a change 
in Avalon which had a bad side effect. I'm in the ones to blame as I 
checked the 2.0.3 before it gets released in its default configuration 
only, which is using the compiled engine.

However, such a bug would have been easily found if we had both 
repeatable unit and functional testing. Testing Avalon components and 
SAX-based components may not be easy, but we have to do it in order to 
improve the stability and our confidence in the code base.

>I still believe that we can solve some (perhaps not all)
>problems simply by organizing our project structure and
>by shifting our activities from "hacking new features"
>to "making a more perfect solution".
>  
>

+10, even if hacking may be the funniest part of the job. But hacking 
tests can be fun also ;)

Sylvain (on a rainy vacation afternoon...)

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message