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
