I was about to commit the POI stuff, but then I felt a bit uneasy with how the current build is organized.
Since there are so many optional components, it has become very big, difficult to maintain IMHO and to understand for starters. Also, the examples are structured better than before, but still a bit confused as with directory structure and, most of all, they create problems with the treeprocessor, that (correctly) complains when a sitemap uses components that are not declared. I've sent some patches for a restructuring of the build in the past, and in the process of cleaning it for POI and Forrest I've created a project called Centipede (http://www.krysalis.org/) that is used as a project starter. I'm not proposing to use Centipede, but I think that some ideas-solutions that came up with it could be applied to Cocoon. DISCLAIMER: This has nothing to do with the current thread on cocoon Blocks. Cocoon Blocks could change in the future some of the things proposed here (optional components will be Blocks?), but IMHO it doesn't invalidate current needs. I could do the following: 1. Make a task that searches, like the xconf tool, in the classpath, for .xoptional descriptor files and decides if a set of resources is to be copied in the build dir (as the build does now in a more extensive way). A sample could be: <?xml version="1.0"?> <xoptional name="BSF" lib-url="http://oss.software.ibm.com/developerworks/projects/bsf/";> <if> <class-available classname="com.ibm.bsf.BSFException"/> </if> <then> <xsamples> <!-- mount samples --> </xsamples> <xconf> <component role="org.apache..." class="org.apache..."/> </xconf> </then> <else> <exclude name="**/ScriptAction.java"/> <exclude name="**/ScriptGenerator.java"/> </else> </xoptional> 2. make all samples to be mounted in a "samples" dir, each with its subsitemap. This could make it easy to not put them in when there are optional components not presents, or also use Cocoon easily without the samples. 3. Structure the build as in Centipede or Forrest by using external entities, by dividing the build targets in many .xpart files. Forrest has an example of this in CVS. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
