You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gk...@apache.org> on 2007/09/09 19:36:58 UTC
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...
Hi Daniel!
danielf@apache.org pisze:
> Author: danielf Date: Sun Sep 9 10:08:24 2007 New Revision: 574029
>
> URL: http://svn.apache.org/viewvc?rev=574029&view=rev Log: Moved ObjectModelTemplate.xml and
> ObjectModel.xml to the cocoon-sitemap-impl module as they depend on the
> CocoonEntryObjectModelProvider.java that is defined there. Beans must follow the same dependency
> graph as the Java classes. Also changed the package of the CocoonEntryObjectModelProvider.java
> 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 providers
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.
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. I hope to be
more helpful in one week.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
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...
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Hi Daniel!
>
> danielf@apache.org pisze:
>> Author: danielf Date: Sun Sep 9 10:08:24 2007 New Revision: 574029
>>
>> URL: http://svn.apache.org/viewvc?rev=574029&view=rev Log: Moved ObjectModelTemplate.xml and
>> ObjectModel.xml to the cocoon-sitemap-impl module as they depend on the
>> CocoonEntryObjectModelProvider.java that is defined there. Beans must follow the same dependency
>> graph as the Java classes. Also changed the package of the CocoonEntryObjectModelProvider.java
>> 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 providers
> 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
dependenicies.
> 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 ;)
/Daniel