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 Wed, 17 Nov 2004 15:05:46 GMT
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

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.

Geoff

On Wed, 17 Nov 2004 07:55:47 -0600 (CST), Antonio Gallardo
<agallardo@agssa.net> wrote:
> Hi Geoff.
> 
> Please change it. I just follow the Niclas' advise. ;-)
> 
> Are there some mock classes to address that?
> 
> Best Regards,
> 
> Antonio Gallardo
> 
> Geoff Howard dijo:
> 
> 
> > And whole of cocoon was not at stake, just the eventcache block.
> > There is one (?)class in eventcache which provides support for JMS
> > messages invalidating cache (which in my original vision was the
> > primary use) and thus this dependency on the JMS api.  Do we in gump,
> > or in blocks build have "conditional"/optional dependencies?  IOW,
> > this block can actually function usefully without JMS except I believe
> > this one impl class.
> >
> > Geoff
> >
> >
> > On Wed, 17 Nov 2004 07:21:00 -0600 (CST), Antonio Gallardo
> > <agallardo@agssa.net> wrote:
> >> Upayavira dijo:
> >>
> >>
> >> > antonio@apache.org wrote:
> >> >
> >> >>Author: antonio
> >> >>Date: Wed Nov 17 05:11:21 2004
> >> >>New Revision: 76124
> >> >>
> >> >>Modified:
> >> >>   cocoon/trunk/gump.xml
> >> >>Log:
> >> >>Fix eventcache. Thanks to Niclas Hedhman.
> >> >>
> >> >>Modified: cocoon/trunk/gump.xml
> >> >>==============================================================================
> >> >>--- cocoon/trunk/gump.xml     (original)
> >> >>+++ cocoon/trunk/gump.xml     Wed Nov 17 05:11:21 2004
> >> >>@@ -905,6 +905,7 @@
> >> >>
> >> >>     <depend project="cocoon" inherit="all"/>
> >> >>     <depend project="cocoon-block-jms"/>
> >> >>+    <depend project="jms"/>
> >> >>     <depend project="cocoon-block-xsp" type="samples"/>
> >> >>
> >> >>     <work nested="build/cocoon-@@DATE@@/blocks/eventcache/dest"/>
> >> >>
> >> >>
> >> > Is this right? Surely it is the cocoon-block-jms 'project' that is
> >> > dependent upon JMS, not the whole of Cocoon?
> >>
> >> The cocoon-block-jms project already had this dependency too.
> >>
> >> Best Regards,
> >>
> >> Antonio Gallardo
> >>
> >>
> >
> 
>

Mime
View raw message