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
