cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [proposal] aiming to a naked cocoon
Date Wed, 12 Feb 2003 10:02:15 GMT
Bertrand Delacretaz wrote:
> Le Mercredi, 12 fév 2003, à 10:12 Europe/Zurich, Stephan Michels a écrit :
>> ...
>> +1, especially moving the libs into the blocks...
> Wouldn't the duplication of jars generate a huuuuuge CVS repository? 
> It's big enough already.

why duplicating jars? FOP relies on fop. Batik relies on batik and so 
on. The blocks that rely on shared jars, will have those jars shared in 
another location. Besides, how many are we talking about?

> An option might be to keep the jars in a well-structured lib/ 
> subdirectory and have the block's build.xml copy the required jars to 
> its workspace before compiling. Easy to do with ant filtered copy task.
> The lib/ could then include "version directories" if different versions 
> of jars are needed for different blocks (at compile time - I know it's 
> going to be a problem at runtime):
>   lib/fop/0.20.1/fop-0.20.1.jar
>   lib/fop/0.20.4/fop-0.20.4.jar
>   lib/fop/0.20.4/some-additional-jar-for-0.20.4.jar
> And then each block pulls what it needs from this tree.

nononononono, versioning is another step down the road for COBs.

People, all those problems are already solved on paper, we just need to 
find a way to move incrementally from here to there.

Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

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

View raw message