Nicola Ken Barozzi wrote:
>
> 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>
I don't like the markup semantics but I see your point and I like the
concept.
> 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.
I like this so far.
> 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.
I don't like this, we should stay away from entities as much as
possible.[also true for forrest, I'd love that to be changed]
What do others think about this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
