On 18-nov-04, at 22:21, Geoff Howard wrote:
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).
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.
-- Unico
