cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Introduction of cocoon-container core module
Date Sat, 11 Aug 2007 12:21:15 GMT
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev: 
> Why are you depending on CocoonTestCase for testing the expressions? 

I think it's mostly a matter of convenience. CocoonTestCase or ContainerTestCase sets up almost

everything I need so I can write good test in few lines. As we see, it's not perfect because
introduces lots of dependencies.

> 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 
> org.springframework.test.AbstractDependencyInjectionSpringContextTests 
> would do what you need. Take a look at testing with the Spring framework 

Will read it now.

> 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 
> modules.

Daniel, could you take a look at these[1][2] test cases and give an advice what to do with
tem? I'm 
still learning an some real life example would help me to grasp directions.

ExpressionTestCase tests if ExpressionFactory properly returns compiled expression for all
expression languages. Do you suggest to manually inject all compilers to ExpressionFactory?

FOMTestCase tests if expressions work well with ObjectModel and environment data. According
to what 
you said, I should move this test to cocoon-sitemap-impl, right?

Moving tests of expressions to cocoon-sitemap-impl is quite weird for me. Am I only one feeling

>> 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.

Only tests (scope=test in Maven) would depend on bridge but I agree with your standpoint.
I also 
realized that bridge depends on lots of stuff from Cocoon, especially on components interfaces.
means won't really clean dependencies but I think we don't have to strive for it. All in all,
bridge is temporary (although, long-term) solution.

> 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.

I had the same goal (decreasing the number of dependencies) in mind but chose wrong approach.
though I think we should move bridge to cocoon-container I won't work on it now because it
does not 
solve my current problems.

I'll get back to it when time permits.


Grzegorz Kossakowski

View raw message