cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: Cocoon in Business Environements and its shortfalls
Date Thu, 28 Aug 2003 15:15:36 GMT
Robert Simmons wrote:
> I wanted to open a general discussion thread on the shortfalls of Cocoon in
> business environments. I have some very clear opinions on the matter, but
> then my opinions are just that -- opinions. Others may differ with me.


> I will start by stating my issues with cocoon as is:
> 1) Production builds are lacking. What I mean by this are builds that a
> developer would use if he is USING cocoon and not developing on it at all.

Robert, I think you are making the (understandable) assumption that 
getting rid of the binary build betrayed a focus on people developing on 
Cocoon itself, but this is incorrect.  Have you found the recent (last 
week or two) comments I made explaining this on the users list?  I have 
had several people with the same initial feeling you're expressing write 
back to me privately after that indicating that the current (temporary) 
solution is not nearly as bad as they perceived it to be.

To restate simply, the build step really is a "configure" step and a 
build step rolled into one.  We could probably (now that the JDK 
dependencies are fixed) distribute a "half built" Cocoon, where all 
classes are compiled but the webapp is not configured/assembled.  That 
would not get you out of having to run ./ target-name to do 
the last step.  So it has been the judgement of the community that since 
that's necessary anyway, there is not a big functional difference 
between the two and what we have can do for now.  We could probably 
rename to and remove the bulk of the perception 

> 1a) One might object that blocks have to be described dureing the build
> process. This could be true but needs to change. The ideal solution is that
> someone cha drop in a block into the blocks directory post build and then
> indicate the block in the sitemap. This would allow a binary build that
> would give users the chance to merely delete blocks that they are not
> interested in and add their own blocks to a binary build.

You need to note that we already have an excellent solution in the works 
which will allow binary drop-in of new components/applications/services 
into a pre-built binary core.  I believe this will exceed most people's 

We just released 2.1.  Planning for the next step has been in the works 
for probably a year and execution is beginning now.

> 1b) Examples for blocks need to be out of the blocks themselves. In my
> opinion, the only thing in the blocks directory should be the blocks jars
> themselves and perhaps something akin to a deployment descriptor for the
> blocks in the directory. Examples should be in a completely different
> locations.

Are you aware that including a block with exclude.webapp.samples (or 
whatever) configured excludes the examples for that block already? 
Given that, I completely disagree that the samples should be moved 
somewhere else.  A block (as it exists now, not in the full 2.2 
implementation under development now) is not a discrete thing that can 
be picked up and deleted.  It's an aggregation of java classes and 
configuration, and (optionally) samples.


> 4) Cocoon documentation is minimal and non-cohesive. (But you knew this
> already) Although wiki is good for knowledge sharing, the information in
> Wiki is oftewn out of date and its reliability is sometimes questionable.

Unfortunately, so is the "official" documentation in places.  Newcomers 
who don't feel comforatble writing new docs could still help immensely 
in giving good detailed feedback about what is missing, what is out of 
date or questionable, and what should move from the wiki to the official 


View raw message