cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: What's going on with gump?
Date Mon, 03 Apr 2006 09:07:22 GMT
Reinhard Poetz wrote:
> Upayavira wrote:
>> Reinhard Poetz wrote:
>>> Bertrand Delacretaz wrote:
>>>> Le 3 avr. 06 à 09:08, Gump a écrit :
>>>>> ... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to
>>>>> project name
>>>>> -INFO- Failed with reason missing build outputs
>>>>> -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/
>>>>> lib/optional/chaperon-20040205.jar
>>>>> -ERROR- No such directory (where output is expected) : /usr/local/
>>>>> gump/public/workspace/cocoon/lib/optional...
>>>> What's up here? Is gump trying to build the trunk with the old ant
>>>> build system?
>>>> I'm not too sure about where to look for details on what exactly
>>>> gump is trying to do....
>>> The error above seems to be caused by the missing lib/optional directory
>>> as I removed them last week.
>>> If somebody wants to reactivate gump again, he should start
>>> incrementally and write a gump descriptor for cocoon-core but please
>>> make sure that we don't have any svn:externals in trunk; I removed the
>>> svn:externals link to gump.xml.
>> Well that is going to break things. That SVN external was to allow Gump
>> people write access to our gump descriptor. How come you removed it? It
>> was placed there in discussion with this list and with the Gump peeps.
> Sorry for not bringing this issue to the list.
> IIUC I didn't delete the descriptor but only the link to it as gump.xml
> is located in the gump SVN. We can add the svn:external to our
> repository for convenience but please don't do it within trunk -
> /cocoon/gump would be a better idea IMHO.

Actually, this is fair enough, as we no longer depend upon Gump for our
build process.

>                                    - o -
> More generally, we need to decide what we do with it as gump.xml as it
> is today is totally broken because of the move to Maven 2 (e.g. we are
> relying on many libraries within the repository; many source directories
> have changed, etc.).
> Basically the gump descriptor expresses the same dependencies as the
> pom.xml and I doubt our community will take care of both. BTW, is
> anybody taking care of a working Gump descriptor? The best solution
> would be Gump that can work based on pom.xml descriptors ...

I did see some discussion on Gump working with Maven2, but have since
unsubscribed from general@gump, as I was hardly reading it.

So in time, maybe Gump itself will run off pom files where they exist.

Regards, Upayavira

View raw message