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 ./something.sh 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 build.sh to configure.sh and remove the bulk of the perception problem.
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 expectations.
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 docs.
Geoff
