Jay, I think your post is just as valuable in the users group as well as in dev. Although what we are trying to do with Cocoon may be somewhat different, I believe the approach you are suggesting comes pretty darn close to what I need. Although I don't need all the cocoon parts and am OK with the blocks concept, your approach to dealing with the configuration files is just what the Dr. ordered.
Ralph -----Original Message----- From: Jay Freeman (saurik) [mailto:[EMAIL PROTECTED] Sent: Saturday, August 16, 2003 5:41 PM To: Ralph Goers Subject: Fw: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??) Ralph: I don't know if you are on the cocoon dev list, I did a search through my mail and I only saw you post on the cocoon users list, but I sent this to the dev list a little earlier (I had figured I'd not do rampant cross-posting) and, after hearing your comments about "JUST my stuff" I was wondering what you thought about it. Feel free to send replies to this back to either mailing list if you feel that appropriate; I sent this directly to you as it's really just a forward from the other list that I wanted you to see and I wasn't really adding any new information content to it :). I also tacked a reply that I sent to this post at the end. Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] ----- Original Message ----- From: "Jay Freeman (saurik)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 16, 2003 5:58 PM Subject: 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/[EMAIL PROTECTED] > 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) > [EMAIL PROTECTED] > > ----- Original Message ----- > From: "Geoff Howard" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > 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 ----- Original Message ----- From: "Jay Freeman (saurik)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 16, 2003 7:19 PM Subject: Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??) > 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) > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
