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 Fri, 19 Nov 2004 00:31:52 GMT

On 18-nov-04, at 22:21, Geoff Howard wrote:

> On Wed, 17 Nov 2004 16:25:46 +0100, Unico Hommes <> 
> wrote:
>> Geoff Howard wrote:
> ...
>>> 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:
> ...
>>> - 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.
> ok, ok :)
> What I meant to communicate was that someone didn't just recently add 
> some
> new functionality here and slip in a big "dependency" in the loosest
> sense (not gump or even ant sense).

Off course. I didn't mean to provide an argument for or against your 
previous points. In fact - I should have made  that clear - I 
completely agree with them.

>>> 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.
> So, Unico do you agree that this dependency (all meanings) is OK here 
> or do we
> need to try a conditional dependency as Stefano mentions in another
> thread (thanks by the way S.)?

Yes I think the dependency is correct. Off course it would be ideal to 
have conditional dependencies in our build system. But that's a 
separate issue IMO.


View raw message