cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: svn commit: r574029 - in /cocoon/trunk/core: cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ cocoon-sitemap/cocoon-sit...
Date Sun, 09 Sep 2007 20:03:05 GMT
Grzegorz Kossakowski skrev:
> Hi Daniel!
> pisze:
>> Author: danielf Date: Sun Sep  9 10:08:24 2007 New Revision: 574029
>> URL: Log: Moved ObjectModelTemplate.xml
>> ObjectModel.xml to the cocoon-sitemap-impl module as they depend on the
>> that is defined there. Beans must follow the
same dependency
>> graph as the Java classes. Also changed the package of the
>> from o.a.c.el.impl.objectmodel that is defined in the cocoon-expression-language-impl
module to
>> o.a.c.objectmodel.impl that only is used in the cocoon-sitemap-impl module. Please
avoid split
>> packages, where some of the classes in the package are in one module and the rest
in another.
> I agree with your point about dependencies but I don't like your solution of moving stuff
to already
> overloaded cocoon-sitemap-impl module.
> Actually, whole problem with dependencies comes from the fact that this snippet:
> <property name="initialEntries">
>   <map>
>     <entry key="cocoon" value-ref="o.a.c.el.impl.objectmodel.CocoonEntryObjectModelProvider"/>
>     <entry key="Packages" value-ref="o.a.c.el.impl.objectmodel.PackagesEntryObjectModelProvider"/>
>     <entry key="java" value-ref="o.a.c.el.impl.objectmodel.JavaEntryObjectModelProvider"/>
>   </map>
> </property>
> was considered as temporary that I forgot to state clearly which is my fault. This static
map should
> be just replaced by <configurator:bean-map/> that would collect all ObjectModel
> dynamically at runtime. If you do this and take care of beans renaming so keys in Map
are properly
> created by <configurator:bean-map/> there is no need to move anything.

OK, that seem like a better solution. But until that is implemented, it 
is better that component dependencies are syncronized with module 

> Obviously, there is some clean up work left in EL code that I intended to perform just
after I
> settle with my current top-priority affairs like passing exams or finding new flat.

Seem like a reasonable priority ;)


View raw message