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
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
