On Wed, 17 Nov 2004 16:25:46 +0100, Unico Hommes <[EMAIL PROTECTED]> 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
