cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <>
Subject Re: svn commit: rev 76124 - cocoon/trunk
Date Wed, 17 Nov 2004 15:25:46 GMT
Geoff Howard wrote:

>Please change what?  Remove what is viewed to be a key use-case of a
>block to avoid a dependency?  Move one class into its own block?
>(there are very few classes in the event cache block anyway).
>The jms event cache item could also be moved into the "jms" block, but
>that then introduces a deep dependency of the jms block to event
>cache, which also is not required and people would complain there.
>I guess my question about optional dependencies gave the wrong
>impression of the utility of jms in event cache.  I don't think it's a
>problem having a dependency on the jms api in this block because:
>- It's not introducing a new jar into our cvs
>- It exists for the primary envisioned use of the block (though there
>are other possible uses as I noted)
>- It's an API dependency, not an implementation dependency - you don't
>have to have a full JMS server unless you want to use the JMS
>- This is not a new dependency - it's been there I think from the
>first commit, though maybe shortly after and was always the intention

Actually, not quite true [1]. The JMS listener for eventcache used to be 
located in the jms block. I moved that functionality to the eventcache 
block as part of refactoring work I did on the jms block. The dependency 
from eventcache to jms seemed more logical to me than the other way 
around. Unfortunately, it turned out that the jms samples also rely on 
the eventcache block, so that a virtual cyclic dependency broke the 
build at that point. The temporary resolution I did was to comment the 
samples- dependency from jms to eventcache in gump.xml.

>Niclas' advice is the only way to fix gump.  Why this is the first
>it's come up is a mystery to me, but IMV the dependency should have
>been there all along.

I see two possible reasons the problem only surfaces now. The first is 
that it may be due to a recent change in the build system. Previously 
declaring a dependency on another block meant that it would inherit all 
of *its* dependencies as well. Now that is nolonger the case, at least 
in the 2.1.x branch. Second, it has been a long time since gump last 
built the blocks successfully. So the change in the direction of the 
dependency could have gone unnoticed by gump untill now.


View raw message