cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Introduction of cocoon-container core module
Date Sat, 11 Aug 2007 11:52:04 GMT
Grzegorz Kossakowski skrev:
> Hello,
> I'm playing with COCOON-2110 at the moment and run into problem with 
> writing test for new functionality.
> Our current code is messed a little when it comes to modules affilation. 
> For example, our Avalon-Spring bridge[1] code is in cocoon-sitemap-impl 
> module. Tests[2] for functionality (PreparedVariableResolver class) 
> belonging to cocoon-sitemap are in cocoon-core. This two examples are 
> the most prominent but there are some more.
> I'm especially interested in PreparedVariableResolverTestCase because I 
> want to write tests for my code handling new expression evaluation. I 
> need dependency on cocoon-expression-language-impl in cocoon-core, of 
> course. The problem is that cocoon-expression-language-impl already 
> depends on cocoon-core because it makes use of o.a.c.CocoonTestCase 
> defined in core. This introduces an cyclic dependency.

Why are you depending on CocoonTestCase for testing the expressions? 
AFAICS, you are not needing anything from CocoonTestCase at all for 
testing expressions. Most of the testing can be done on the bean level 
with pure Junit and for the integration tests, where you want to test 
the configuration files, I would assume that 
would do what you need. Take a look at testing with the Spring framework

If you feel like testing how the expression mechanism works in a 
complete sitemap environment, that is part of testing the sitemap rather 
than testing the expressions and should be done in the sitemap or core 

> Similar situation occurs when I want to move 
> PreparedVariableResolverTestCase to the cocoon-sitemap-impl module. 
> Having said that I would like to propose introduction of new core module 
> 'cocoon-container' where I would move our Avalon-Spring bridge, base 
> TestCases and other related stuff.

Having an own module for the Avalon-Spring bridge seem like a good idea 
(although it probably require some refactoring to get reasonable 
dependencies). But I don't see why it should contain base test classes. 
As we are moving away from Avalon we should strive to remove the 
dependencies on the Avalon-Spring bridge successively. So I really don't 
want the expression abstractions depend on the Avalon-Spring bridge.

> This way we should have cleaner dependencies and more freedom when it 
> comes to moving stuff. I've already played with such approach locally 
> and as for now it seems to work well.
> Thoughts? Objections?

The main thing with dependencies is that they should be few. The 
reusability of a module decreases rapidly with increasing number of 
dependencies. Please take a look at for 
understanding the goals with the splitting up of the Cocoon core in 
smaller modules. The core split is in no way finished so you are of 
course welcome to continue the work. But please respect the main 
direction of *decreasing* the number of dependencies.


View raw message