Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <31DF72A980E5D511B48C000102BD868503EA7EE4@calexc01.diginsite.com>
From: Ralph Goers <Ralph.Goers@digitalinsight.com>
To: "'users@cocoon.apache.org'" <users@cocoon.apache.org>
Cc: dev@cocoon.apache.org
Subject: RE: [ANN] Apache Cocoon 2.1 Released - binary??
Date: Sat, 16 Aug 2003 17:33:36 -0700
MIME-Version: 1.0
Content-Type: text/plain

Personally, I don't really care whether cocoon ships as a binary or not.  In
fact, to ship as a binary, each of the blocks would need to be in its own
jar file.  From a documentation perspective this might be better as it is
easy to see which blocks are being included in a product.

What I need is to be able to access a set of jars and a basic set of
configuration files that I can then incorporate into MY build (i.e. it is
unacceptable to build my stuff as part of the cocoon build).  This means I
need to create my own cocoon.xconf and sitemap.xmap that has JUST my stuff.
The sitemap.xmap and cocoon.xconf should only have definitions for the
cocoon core components.  In fact, the default cocoon build SHOULD NOT even
build the samples web site as I certainly don't want that as part of my
product.

Ralph 

-----Original Message-----
From: Geoff Howard [mailto:cocoon@leverageweb.com]
Sent: Saturday, August 16, 2003 3:21 PM
To: users@cocoon.apache.org
Cc: dev@cocoon.apache.org
Subject: Re: [ANN] Apache Cocoon 2.1 Released - binary??


Sam Chance wrote:
> As a user...the binary is essential.  I understand it makes it easier for
> the developers, but I think the issue needs to be revisited with an intent
> to distribute a binary.

Ok, first of all - I hear you and will raise this issue again on the dev 
list. (cc'd).  Can I ask you to elaborate on why you think the one step 
build is just out of the question for you?  Is it the ease of first use 
when evaluating?  Is it the build time?  Is there something not provided 
that is needed?  Honestly, everyone has been very open minded about this 
but had a hard time coming up with a quantifiable reason.

But also,
- just to reiterate.  This was not meant to make it easier on the 
developers, but the users.  It was observed that Cocoon is not really a 
thing that you just "use" -- it's a framework that lets you develop 
something.  And starting that process was very painful with a binary 
distribution and it is much better with the current one.  There is just 
so much in the distribution that any one person doesn't need all of it.
- this was never intended as a permanent direction for Cocoon.  The 
arrival of hot-pluggable "real" blocks in (probably) the next release 
will give the best of both worlds.

Geoff