gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [GUMP] Build Failure - cocoon-block-slide
Date Mon, 24 Mar 2003 10:29:44 GMT
Stefan Bodewig wrote:
> On Sun, 23 Mar 2003, Stefano Mazzocchi <> wrote:
>>All right. I think I found out the problem: it seems that the gump
>>descriptor for jakarta-slide is incorrect and doesn't expose all the
>>jars that we need and we depend on.
> Quite possible.  Slide used to be unbuildable by Gump for months.
> If you know of any additional jars, feel free to add them.  

I'm not that sure. I found in jakarta-gump/project/jakarta-slide.xml

     <home nested="dist"/>


     <jar name="slide/lib/slide-kernel.jar" id="kernel"/>
     <jar name="slide/lib/slide-roles.jar" id="roles"/>
     <jar name="slide/lib/slide-stores.jar" id="stores"/>
     <jar name="slide/lib/slide-webdavservlet.jar" id="webdavservlet"/>

but from the slide build, it seems that those jars are really found in


Now, what does that <home nested="dist"/> mean? does it make the <jar> 
below relative to the nested <home> or not?

> Unlike the
> Gump descriptors for Cocoon, those for Slide are inside Gump's CVS
> module and can be changed by *all* Apache committers ;-)

Yes, I'm fully aware of this and you are not the first one to suggest me 
to move it back to Gump. The are two problems, though:

1) technical: the gump descriptor is used *directly* by the cocoon build 
system to generate (via xslt) the ant build file used to produce our 
internal blocks (we call 'cocoon functional modules' blocks)

Since we can't expect everybody to have a CVS connection everytime they 
what to do a build, while gump *does* need a CVS connection anyway, I 
think it's better for our developers this way.

2) community: the cocoon community has been ignoring gump and all XP 
practices of unit testing and continous integration. This *has* to 
change and getting gump to build has been a major issue for both Avalon 
and Cocoon in order to remove the 'build on unreleased code' (aka 'build 
on sand') attitude that has been plaguing us and leading us not to be 
able to release early and often as we should have done.

Now, having the gump descriptor in gump will lead the perception that 
*somebody* will fix it anyway. This normally happens, but this doesn't 
allow the cocoon community to appreciate the value of such a system and 
how difficult it is to get all the microcontracts straight and how easy 
it is to break things around by doing locally harmless changes.

I don't know, maybe I'm wrong, but at least I'm trying to make things 
change a little.


View raw message