cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
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 (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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message