Then cocoon became very complex and we decided to create a binary distribution to make things easier. Things were indeed easier for new users to install and try out, but it was harder for them to actually *do* something with cocoon and tune it for their needs.
The fact that there is even a sourceforge project about a 'clean' version of our shipped cocoon WAR feels a little like a slap in our face.
Then the 1.3/1.4 JDBC incompatibilities came out, forcing us to do two different binary releases.
Now, in the light of a cleaned-up build system and a very-well-factored-out static block architecture and the inclusion of a super light-weight servlet container, I think we are ready to finally go back to where we started and stop releasing binaries.
Before you jump up and down and scream "no, no, binaries are easier for our users", get off your life-without-a-compiler-windows-inflicted-mindset and think that every JDK comes with a compiler.
To be really honest, Cocoon already includes not one but *TWO* java compilers!!! we could build from javawebstart if we really wanted to! (we should also decide if we want to remove pizza from the distribution!)
So, in light of the good old triad
./configure; make; make install
I propose to ship Cocoon 2.1 *AS IS*, sort of a cleaned-up version of our current CVS and improve a little the 'INSTALL.txt' doc that will suggest you to do
$> ./build.sh $> ./cocoon.sh servlet
and voila', that was it! or, if you really want to deploy stuff into your wervlet container do a simple
$> ./build.sh war
and you are done.
And next step, when you want to tune your distribution for your needs simply do
$> cp build.properties local.build.properties $> cp blocks.properties local.blocks.properties
then edit them, then
$> ./build.sh clean $> ./build.sh $> ./servlet.sh servlet-admin &
so you can start/stop/restart your cocoon without having to star/stop jetty from the command line.
What do you think?
Stefano.
