Stefan Bodewig wrote:
On Sun, 23 Mar 2003, Stefano Mazzocchi <[EMAIL PROTECTED]> 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

dist/slide/lib

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.

Stefano.




Reply via email to