cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Freeman \(saurik\)" <sau...@saurik.com>
Subject Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??)
Date Sat, 16 Aug 2003 22:58:38 GMT
The #1 thing that would help me start using Cocoon is orthogonal to a
binary/source distribution issue (and I'll note my preference is towards
binary on this axis).

I agree with you (and the previous arguments, I read through the entire
thread that was linked to) that taking Cocoon and getting it into a state
where I can start making changes to it is one of the most irritating steps
to getting Cocoon working. However, 2.1 hasn't changed this all that
terribly much. (If you look at this e-mail and go "oh, he doesn't know how
to use the build environment", please skip to "[START HERE]" later in the
post before making a snap judgement on my point. If you want to just see
what I'm proposing, skip to [PROPOSAL], although that skips part of the
explanation of "why?".)

The biggest issue to me is that Cocoon draws the line between where it ends
and my application begins at a different place than I do. To me, my
application is a few lines in the map:components section, almost all of
map:pipelines, and one or two configuration blocks in cocoon.xconf (usually
one). Everything else is "Cocoon", the framework on which I'm developing my
application.

When I've seem people in some of these threads talking about using the
custom build environment to get only what they want, I get the impression
that they are talking about things like "don't install SVG support". To me,
I want _all_ of that installed. It's like installing a Linux distribution,
and knowing there's some command line program that would be really useful,
having many, many gigabytes of space devoted to /usr/bin, and _still_
deciding "no, I don't want that". I ask back: WHY?!? :) Or like having Java,
and deciding "no, I'm never going to use java.util... I'm going to uncheck
the box and not intall it".

So when Stefano made the following point:

maybe not all of them are beareded unix gurus (BTW, all the unix gurus I
know don't have a beard, sign of the generation changes?) but for sure
all of them want to use Cocoon to build stuff and I think (but maybe I'm
wrong) they'd rather start small and grow than start huge and dismantle.
[
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=cocoon-dev@xml.apache.or
g&msgNo=12663 ]

I want to say I agree with him for the actual application. I'd rather write
that myself. But I don't want to have to go "wait, I need SVG support...
well, let's map that into the sitemap and do this and do that...".

Having a tiny webapp that only contains the framework features I need is the
least of my concerns when I'm trying to get Cocoon working. What I want is
the _entire_ framework to get installed, and absolutely _no_ application.
This means I want almost (this almost is because some are samples) every jar
file Cocoon has to offer me, almost every
generator/transformer/serializer/reader, almost every taglib, a pipeline
devoid of anything at all except an error handler, and a virtually empty
webapp context directory (at most one directory other than WEB-INF for the
files needed for the default error handler, assuming these can't go in
WEB-INF/error... I never checked to see if the pipeline is allowed to read
out of there...). If there was a really easy way to get to this point,
binary _or_ source, _I'd_ be super super happy.

Now, this doesn't apply to services. I look carefully at what
web/mail/whatever servers are going to get installed. In the case of Cocoon,
this would be HSQL. I don't use it, I have my own SQL server, I would prefer
it be installed (no harm in having the jar there), but be configured off so
it doesn't keep starting, listening on some port, and consuming whatever
resources it uses when it's actually _running_ (something unused generators
don't do).

What ended up happening to me with Cocoon 2.1 is I downloaded the new source
distribution and then had to learn the new build environment to try to get
it to do that for me. Note that the new build environment doesn't seem to be
terribly documented... I did some recursive greps on the distribution to try
to figure out what some of the exclude.* options did and was only greeted to
build.xml files (of which were heavily factored out to use different
variables to store things and beyond my comprehension at the time).

I turned off all the samples I could find, even added some exclude.* options
that I found during the course of my grep that weren't even in the original
build.properties file. What I ended up with still had HSQL, but that's
apparently because I didn't notice the block that would turn that off.
However, my goal isn't really to turn that _off_ as much as would be to
supress the configuration for it. I'd still want the jar there.

[START HERE]

I guess a big issue is that I not only host Cocoon for me, I host Cocoon for
other people on my web server. I try to offer it to them at the level of
"here, go ahead, build yourself a webapp". If I tell them to ignore the
map:components section, and to never ever look at cocoon.xconf, this
actually works quite well. I have people happilly writing Cocoon
applications who wouldn't be able to set it up for themselves on their own
computers.

So to me, Cocoon is _extremely_ a framework. It's just like installing PHP
on the computer and adding the little "yes, we support that feature" box in
the "what we offer as a hosting provider" section (now, these are just
friends of mine, it's not like I'm selling a service or something). If my
users want to use HSQL, I want the jars to be there and ready to go, they
would just need to configure it by adding a few simple XML elements to some
configuration file and then restarting their webapp (functionality I give
them through Jakarta so they can restart Cocoon if they want to upload new
jars for some class library they need).

Now, this puts me in the position of upgrading their copies of Cocoon. The
process of upgrading both their websites and mine is grueling right now. The
pipelines themselves have pretty much stayed the same since the introduction
of Cocoon 2, but I still need to deal with everything else. First I go
through cocoon.xconf to unconfigure HSQL and the default database source
that always gets configured (I'm pretty sure it got configured in 2.1 even
though I wanted no samples... I did want the authorization framework, just
no samples).

Then I do the same thing to the sitemap. This was a little easier than
before as most of the pipeline was clear. However, I still had to do it.
There were some default pipeline entries for things like "" that pointed to
a welcome screen that I didn't want. Also, the files required for the error
handler are strewn all about... some in stylesheets/system,
resources/scripts, resources/style, and the root directory of the webapp. I
then move all of those into a single folder and redo the sitemap
appropriately. No matter who I'm setting up Cocoon for, myself or my users,
the error handler is crucial to doing development. I obviously want it. But
having it's files strewn all over the place is really irritating.

Now comes the great merging of the sitemaps. My users haven't started
writing custom generators and transformers, but I have for some of my own
websites (I'm working on an EXIF generator for grabbing digital camera
information from JPEG files based on some classes from a guy named Drew that
I found on the web). What would be ideal is if I could just copy the new
framework configuration over the old one (as I really don't touch any of
that), and leave my application configuration alone.

However, as mentioned before, Cocoon doesn't draw that line where I do. I
draw that line halfway through the configuration files :). The #1 thing that
would help me (and I consider myself rather experienced with cocoon), and
I'd imagine help a lot of beginners alike, is to have 4 main configuration
files instead of 2. Yes, that's more, but it's going to add a lot of
"seperation of concerns", and I know we love that, hehe.

[PROPOSAL]

What I would want is for each current configuration file to get split in 2,
one for base configuration, one for local configuration. For the sitemap,
the pipelines go in the latter (although error handlers can be defined in
the prior one and overridden in the latter), and components can go in either
(the configurations here are merged, although names from the latter override
names from the former). Similar process for cocoon.xconf. All the
configuration of how XSP works stays in the base configuration, buy my
single jdbc datasource configuration entry goes in the local one.

This way, I could download a new version of Cocoon (either binary or source,
whatever) and just copy over the old configuration on all of my websites,
merge the jar files (this is irritating... it would be really nice if we
could have a local-lib or something in WEB-INF that specified the jar files
that were particulr to the Cocoon application and didn't have to do with
Cocoon itself, although I realize that may be really hard or even impossible
if it causes issues with the Servlet standard) and as long as my pipeline
was still compatible it would work. I wouldn't need to do the three way
merge operation between my version's pristine sitemap, my sitemap, and the
new pristine sitemap.

Also, this would mean that I'd have files that were just my app. I wouldn't
have to scroll down almost _300 lines_ (and that's using my formatting of
the XML files, which is a hell of a lot more compressed than what it comes
with) in the sitemap.xmap file to find something I consider mine (or find
the _one configuration block_ in cocoon.xconf that I consider mine). One of
the big hurdles _I've_ had to go through when I try to teach new users how
to work with Cocoon is to tell them: "The map:components section may seem
really scary and has lots of configuration; but you really don't have to
know how that works for you to use Cocoon. All you really need to know is it
sets up the default generators/transformers/serializers... don't break it."

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

----- Original Message -----
From: "Geoff Howard" <cocoon@leverageweb.com>
To: <users@cocoon.apache.org>
Cc: <dev@cocoon.apache.org>
Sent: Saturday, August 16, 2003 5:21 PM
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


Mime
View raw message