cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [proposal] a new kind of 'dist'
Date Sun, 23 Mar 2003 14:25:17 GMT
In the beginning, there was only one cocoon distribution, packaged with 
two different packagers (zip for windows and tar.gz for unix and friends).

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.


Mime
View raw message