cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Date Wed, 24 Mar 2004 01:44:21 GMT
On 24.03.2004 01:53, Geoff Howard wrote:

>> This was the reason for the common classpath, wasn't it? I wanted to 
>> have a look on it after having reverted the common classpath, but I 
>> guess that's no longer needed. Thanks for it. BTW, which block depends 
>> on other block's samples?
> 
> 
> Not sure if this is what you mean, but there are some interdependencies 
> between block samples involving (I think) database, hsql, eventcache, 
> jms, and maybe repository.  No block depends outright on samples, but 
> samples do depend on other blocks where the dependency disappears 
> without the samples.

I hope no block's core code is depending on another block's samples code 
and we will not introduce such a dependency as this would break 
compiling if one excludes the samples from the build. What I meant was 
one block's samples dependent on another block's samples (all about 
compiling Java files).

> I would prefer to see some conditional build steps 
> to allow "soft" dependencies for samples and even optional pieces of 
> code.  IOW, some bits are included if the dependency is met, otherwise not.

Indeed. At the moment in gump.xml both sample and compiling dependencies 
are mixed and sometimes not specified at all (e.g. OJB samples depend on 
CForms). AFAIK there is no strict handling of gump.xml and Gump does not 
stumble about additional attributes, so we might add an @type to the 
dependency element. This can be used for better dependency information 
in blocks.properties and maybe also for blocks-build.xsl

Joerg

Mime
View raw message