You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Jay Freeman (saurik)" <sa...@saurik.com> on 2003/08/17 00:58:38 UTC
Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??)
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" <co...@leverageweb.com>
To: <us...@cocoon.apache.org>
Cc: <de...@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
Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??)
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
Steven:
Ooo... I actually noticed in the last few hours that subsitemaps inherit the
parent's component definitions (was trying to figure out Chaperon for doing
syntax highlighting of my Subversion repositories, and was reading through
its sample's sitemap). That _could_ help me with the hosting half of the
issue, as well as the "my sitemap looks cluttered" part, as I could have
everyone's actual sitemap be a subsitemap of something I hide away from them
in WEB-INF. To see you mention it as something you do pushes it up the list
on things I need to look into today :). Thanks.
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Steven Noels" <st...@outerthought.org>
To: <de...@cocoon.apache.org>
Sent: Sunday, August 17, 2003 12:19 AM
Subject: Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon
2.1 Released - binary??)
> Jay Freeman (saurik) wrote:
>
> > Are you recommending that I do all of my development as a patch to a
sitemap
> > rather than as a sitemap,
>
> It won't help you ATM, but for the xconf, that's the way we work with
> Cocoon on our projects... the project sitemap however is mounted as a
> subsitemap, and contains explicit definitions for all components
> relevant to that project.
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon
2.1 Released - binary??)
Posted by Steven Noels <st...@outerthought.org>.
Jay Freeman (saurik) wrote:
> Are you recommending that I do all of my development as a patch to a sitemap
> rather than as a sitemap,
It won't help you ATM, but for the xconf, that's the way we work with
Cocoon on our projects... the project sitemap however is mounted as a
subsitemap, and contains explicit definitions for all components
relevant to that project.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??)
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
Geoff:
I don't see how this would help... what I am proposing is a seperation
between "cocoon" and "my app" so when I look at my sitemap I don't have to
scroll through a bunch of components that I consider "part of cocoon" to get
to my actual pipeline and the 2 components I added manually which I consider
"part of my app". This would also make it much easier to upgrade in the
future.
Are you recommending that I do all of my development as a patch to a sitemap
rather than as a sitemap, and then whenever I want to test it I patch the
pristine sitemap?...
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Geoff Howard" <co...@leverageweb.com>
To: <de...@cocoon.apache.org>
Sent: Saturday, August 16, 2003 9:23 PM
Subject: Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon
2.1 Released - binary??)
...
> I haven't had time to read through your full email enough to do it
> justice, but you may find that the xpatch task may help with some what
> you discussed. I'm currently refactoring an app from very early 2.1 cvs
> and it's helped me. See
> http://wiki.cocoondev.org/Wiki.jsp?page=CustomConfigTarget and the
> xpatch explanation linked to from that page.
>
> HTH,
> Geoff
>
>
Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon
2.1 Released - binary??)
Posted by Geoff Howard <co...@leverageweb.com>.
Jay Freeman (saurik) wrote:
> I forgot to mention this, but if people like this idea I'd be willing to be
> the one to actually have to try to make it happen.
>
> Also, I'd like to point out the way I've envisioned/described it would be
> backwards compatible with the current setup and a blank base configuration.
> The case of cocoon.xconf would be to just increase the search path for
> configuration to both files, so having all the configuration in the local
> file shouldn't be a problem, and having all the components configured in the
> local file also wouldn't be a problem (the base cocoon.xconf could even just
> be detected as "not there" and ignored, and the base sitemap could just not
> be specified in cocoon.xconf and therefor not looked for).
>
> The last thing is maybe there's some obvious way to actually do this
> seperation of configuration now and I just never knew about it.... in which
> case, anyone mind letting me in on the secret? :) Please? hehe
I haven't had time to read through your full email enough to do it
justice, but you may find that the xpatch task may help with some what
you discussed. I'm currently refactoring an app from very early 2.1 cvs
and it's helped me. See
http://wiki.cocoondev.org/Wiki.jsp?page=CustomConfigTarget and the
xpatch explanation linked to from that page.
HTH,
Geoff
Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??)
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
I forgot to mention this, but if people like this idea I'd be willing to be
the one to actually have to try to make it happen.
Also, I'd like to point out the way I've envisioned/described it would be
backwards compatible with the current setup and a blank base configuration.
The case of cocoon.xconf would be to just increase the search path for
configuration to both files, so having all the configuration in the local
file shouldn't be a problem, and having all the components configured in the
local file also wouldn't be a problem (the base cocoon.xconf could even just
be detected as "not there" and ignored, and the base sitemap could just not
be specified in cocoon.xconf and therefor not looked for).
The last thing is maybe there's some obvious way to actually do this
seperation of configuration now and I just never knew about it.... in which
case, anyone mind letting me in on the secret? :) Please? hehe
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Jay Freeman (saurik)" <sa...@saurik.com>
To: <de...@cocoon.apache.org>
Sent: Saturday, August 16, 2003 5:58 PM
Subject: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1
Released - binary??)
...
> 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.
>
...
>
> Sincerely,
> Jay Freeman (saurik)
> saurik@saurik.com
Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Aug 17, 2003, at 00:58 Europe/Rome, Jay Freeman ((saurik))
wrote:
> 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?".)
Have you read the "Cocoon Block" design RT?
--
Stefano.