Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <004f01c2f179$18b224a0$3101a8c0@jdmobile>
From: "J.D. Daniels" <jd@datatrio.com>
To: <cocoon-dev@xml.apache.org>
References: <3E7DC3CD.4090007@apache.org>
Subject: Re: [proposal] a new kind of 'dist'
Date: Sun, 23 Mar 2003 12:16:26 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Well I am just a user... But you hit the nail right on the head there. I had
cocoon up and running within minutes the first time I found it, but was
extremely frustrated for months afterward, because I could load the samples
page... and SEE what it could do, but not be able to implement for myself.
Plus not knowing what I needed for minimal dist made the whole thing the
biggest thorn I had in my side. Cocoon is a unique kind of project. I do not
think the binaries are easier for users.

I have been porting my last three years of PHP development to cocoon. This
has been a most difficult process, especially considering my Java skill
level is in between doughhead and WTF?? (making it confusing and difficult
to debug trouble) The binaries that are available are remarkably confusing.
Since I have started Lurking on this list, and faithfully watching the new
build system settle down, the learning curve has decreased dramatically. If
new new guys want to try it, every peice of beginner information points them
to a servlet container, so it is pretty much garaunteed they will have a jdk
to build with.

 This is a very, very good idea. Lose the binaries and document the build
process a little better.

JD

----- Original Message -----
From: "Stefano Mazzocchi" <stefano@apache.org>
To: "Apache Cocoon" <cocoon-dev@xml.apache.org>
Sent: Sunday, March 23, 2003 6:25 AM
Subject: [proposal] a new kind of 'dist'


> 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.
>