It's funny, but when I read Ralph's comments I got the opposite :). Then again, might just be my perspective. (I even forwarded Ralph a copy of my e-mail and asked him to comment on it.)
First off, you started setting up something that Ralph _specifically_ did not want: your recommendation places Ralph's project inside of the Cocoon build program instead of the other way around. When you download my application and want to build it from source, I would expect it to work like other libraries / frameworks I use: I get a few jar files and some configuration files, I include those with my project, you run _my_ build script, and it generates a war file. That may be possible with some trickery, but I am very confident Ralph was going in that direction, and you tried to turn him back towards the abyss :). To me, the core to be one that, when you start off, you should work with a file that is just your stuff. As in just the stuff that you are working on yourself. That was the core of my proposal: seperating the sitemap configuration into the actual pipelines and custom components you designed for your application, and a base configuration file that contains all the components you don't want to keep seeing every time you edit your file and can then take for granted. At that point what jars and blocks are installed almost doesn't matter... unless you actually look in the WEB-INF/lib folder or open one of these base config files (which I'd imagine most people wouldn't do, only Cocoon developers or people hosting 3rd party Cocoon websites such as myself) you'd never even have to know they are there until you try to use them from your pipeline. Then you could also upgrade Cocoon without having to deal with all this xpatch stuff, you just build the new Cocoon (possibly with whatever exclusions you want), and then drop the new base configuration file directly on top of the old one (overwriting it), replacing the jar files in the lib folder (as I mentioned, there are better solutions to this that may not be possible) and restart Cocoon. This also indirectly solves Ralph's problem. It then becomes easy to treat Cocoon as a large binary distribution that he can include into his project, expand to a folder, overwrite the local configuration files for and copy his stuff into, and then build a war file from. A hell of a lot easier build.xml file to write than what your recommendation would end up forcing. :) Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] ----- Original Message ----- From: "Geoff Howard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 16, 2003 11:32 PM Subject: Re: [ANN] Apache Cocoon 2.1 Released - binary?? > Ralph Goers wrote: > > 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. > > The java classes are already in their own jars. The config and webapp > files aren't and can't realistically be. > > > 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. > > This brings up a great point about the distribution quandry that led to > dropping the binary. A new poster on the dev list (Jay Freeman) is > looking for the exact opposite. He wants the kitchen sink with the > exception of a few blocks, you want the bare bones probably with the > exception of a few blocks. There are many variations on those > requirements and we have to try to accomodate all of them. The solution > we came up with (for now) is a build from source that lets you > include/exclude as much or as little as you want. Defining "cocoon core > components" is way trickier and more subjective than one would think. > > The current system allows for everything you are asking for: > - You don't need to create your own cocoon.xconf or sitemap.xmap because > the build will exclude/include only what you have configured into them. > - The samples are easy to exclude with the new build. > - The documentation is easy to exclude with the new build. > - There is a new target you should investigate which can handle cleaning > up or inserting anything else you need. See > http://wiki.cocoondev.org/Wiki.jsp?page=CustomConfigTarget and the liked > xpatch page. > > Here is an outline of my own build: > - I customize a local.build.properties and local.blocks.properties to > have just what I want. > - In the build properties, I set the build directory (build.dir?) to be > a directory in my separate project area. I call it the "seed" directory. > - I set up a series of patch files that further customize the config > files logkit.xconf, cocoon.xconf, web.xml, and the root sitemap.xmap by > removing, adding and modifying anything I need. I could do all this > manipulation with xslt of course, but for this kind of work the xpatch > system is much more light weight. > - I define the Cocoon xpatch task in my build.xml and use it as part of > the "seed" portion of my build. > - My java and webapp sources are combined with this seed dir to create > my deployable app. > - I can upgrade cocoon by just running through these build steps again > after checking that my xpatch files still accomplish what they were > designed to do. > - This leaves me free to build the main cocoon app many times for > testing or development on Cocoon itself without affecting my application > by simply swapping out properties files before building. > > YMMV, > Geoff Howard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
