cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [PROPOSAL] Reducing the size of the build - ease use of optional components
Date Thu, 07 Mar 2002 00:52:15 GMT
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 ( 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="">
>   <if>
>     <class-available  classname=""/>
>   </if>
>   <then>
>     <xsamples>
>       <!-- mount samples -->
>     </xsamples>
>     <xconf>
>       <component role="org.apache..." class="org.apache..."/>
>     </xconf>
>   </then>
>   <else>
>     <exclude name="**/"/>
>     <exclude name="**/"/>
>   </else>
> </xoptional>

I don't like the markup semantics but I see your point and I like the

> 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.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message