cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <geoff.how...@gmail.com>
Subject Re: svn commit: rev 76124 - cocoon/trunk
Date Thu, 18 Nov 2004 21:21:17 GMT
On Wed, 17 Nov 2004 16:25:46 +0100, Unico Hommes <unico@hippo.nl> 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).

> >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.)?

Geoff

Mime
View raw message