cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Introduction of cocoon-container core module
Date Wed, 15 Aug 2007 17:33:44 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
...
> We use very nice convention for configuration files of TestCases, 
> see[1] especially createBeanFactory method. If we use 
> AbstractDependencyInjectionSpringContextTests we will loose this nice 
> and useful convention.
>
> Any idea about it?
Override
AbstractDependencyInjectionSpringContextTests#getConfigLocation() in
your module specific abstract test class with the following:

    protected String[] getConfigLocations() {
        return new String[] { getClass().getName().replace('.', '/') +
".spring.xml" };
    }

Or put the code in some common abstract test class.

...
>>> Moving tests of expressions to cocoon-sitemap-impl is quite weird 
>>> for me. Am I only one feeling that?
>>
>> First I would propose moving the CocoonEntryObjectProvider to 
>> cocoon-sitemap-impl. By doing that you get rid of the 
>> cocoon-expression-language-impl dependency on cocoon-pipline-api, 
>> which simplifies the dependency graph and makes 
>> cocoon-expression-language more useful outside Cocoon.
>>
>> Then it would probably feel quite natural to test accessing parts of 
>> the Cocoon object model in the cocoon-sitemap-impl.
>>
>> Testing the expression functionality is of course most natural to do 
>> in the expression module.
>
> I see it know! It's that eureka moment! :-)
> I've done what you advised last commits. Now CocoonEntryObjectProvider 
> is in cocoon-sitemap-impl and there is no problem with FOMTestCase and 
> dependencies of cocoon-expression-language-impl are much more cleaner. 
> I'm feeling good because of it. ;-)
:)

/Daniel




Mime
View raw message