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
functionality.
- 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.
1.http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java?root=Apache-SVN&rev=36568&view=log
