You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Upayavira <uv...@upaya.co.uk> on 2004/11/17 14:12:57 UTC
Re: svn commit: rev 76124 - cocoon/trunk
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?
Regards, Upayavira
gump build [was Re: svn commit: rev 76124 - cocoon/trunk]
Posted by Stefano Mazzocchi <st...@apache.org>.
Geoff Howard wrote:
> 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.
if the build breaks when the dependency is not there, then it's a
"required dependency <depend", if it does build (say the ant build file
works around its absence) then it's an "optional dependency <optional"
HTH
--
Stefano.
Re: svn commit: rev 76124 - cocoon/trunk
Posted by Unico Hommes <un...@hippo.nl>.
On 18-nov-04, at 22:21, Geoff Howard wrote:
> On Wed, 17 Nov 2004 16:25:46 +0100, Unico Hommes <un...@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).
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
Re: svn commit: rev 76124 - cocoon/trunk
Posted by Geoff Howard <ge...@gmail.com>.
On Wed, 17 Nov 2004 16:25:46 +0100, Unico Hommes <un...@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
Re: svn commit: rev 76124 - cocoon/trunk
Posted by Stefano Mazzocchi <st...@apache.org>.
Unico Hommes wrote:
> I see two possible reasons the problem only surfaces now.
[snip]
The (rather simple) reason why it surfaces now is that that block was
never built before by gump ;-)
--
Stefano.
Re: svn commit: rev 76124 - cocoon/trunk
Posted by Unico Hommes <un...@hippo.nl>.
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
Re: svn commit: rev 76124 - cocoon/trunk
Posted by Geoff Howard <ge...@gmail.com>.
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
<ag...@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
> > <ag...@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
> >>
> >>
> >
>
>
Re: svn commit: rev 76124 - cocoon/trunk
Posted by Antonio Gallardo <ag...@agssa.net>.
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
> <ag...@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
>>
>>
>
Re: svn commit: rev 76124 - cocoon/trunk
Posted by Geoff Howard <ge...@gmail.com>.
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
<ag...@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
>
>
Re: svn commit: rev 76124 - cocoon/trunk
Posted by Antonio Gallardo <ag...@agssa.net>.
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