You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/03/02 04:08:59 UTC

Re: Gump

Joerg Heinicke wrote:

> On 01.03.2004 07:02, Stefano Mazzocchi wrote:
> 
>>> What about just adding an element for licence location to jars.xml?  
>>> e.g.,
>>
>>
>> Gump descriptors now contain license information and gump is checking 
>> it for you. I think we should use that.
> 
> 
> I think gump would be a cool tool if we would use it correctly or if 
> it's more strict - but maybe I only don't see everything necessary. In 
> theory gump descriptor contains all information about projects, sub 
> projects (our blocks), dependencies and so on. But why for example does 
> our gump descriptor not contain information about all JARs like about 
> joost/stx at the end of the file:
> 
>   <project name="joost">
>     <url href="http://joost.sourceforge.net"/>
>     <description>
>       Streaming Transformation for XML (STX) library
>     </description>
>     <home nested="src/blocks/stx/lib"/>
>     <jar name="joost-20031219.jar"/>
>   </project>
> 
> Is it only a question of maintenance? Or how can the descriptor say that 
> Cocoon core depends on "rhino-cocoondev" but this one is nowhere 
> described? The same is true for "concurrent" and many more. I might be 
> wrong but in theory gump seems to be a perfect replacement for our 
> jars.xml - no need for duplicate effort of maintaining JARs and JAR 
> descriptions. And we don't need to maintain the JAR checker code 
> anymore, just the conversion from gump descriptor to JAR documentation 
> (XDocs).
> 
> Is our gump descriptor that bad maintained? Some time ago we also got 
> gump error messages to the list, now we get those only from persons 
> outside of Cocoon. What's the benefit of gump when we don't use it 
> correctly?

Gump has not been able to run cocoon for the last 6 months at least, due 
to unmet dependencies. As a result, our decriptor is basically dead 
because we haven't been nagged for that period of time.

The gump community is working hard to make this possible again, but this 
is very hard work and takes a lot of time and patience.

My proposal (that the board accepted) to move gump to top level status 
was also to bring more visibility and make projects being more 
gump-friendly, we'll see how this goes.

I have a RT ready for gump that would allow to solve these issues... but 
I need to work more on this since it appears to be a pretty tough 
computational problem of graph analysis.

-- 
Stefano.


Re: Gump

Posted by Stefano Mazzocchi <st...@apache.org>.
Joerg Heinicke wrote:

> Stefano Mazzocchi <stefano <at> apache.org> writes:
> 
> 
>>>... gump as complete replacement for jars.xml ...
> 
> 
>>>Is our gump descriptor that bad maintained? Some time ago we also got 
>>>gump error messages to the list, now we get those only from persons 
>>>outside of Cocoon. What's the benefit of gump when we don't use it 
>>>correctly?
>>
>>Gump has not been able to run cocoon for the last 6 months at least, due 
>>to unmet dependencies. As a result, our decriptor is basically dead 
>>because we haven't been nagged for that period of time.
>>
>>The gump community is working hard to make this possible again, but this 
>>is very hard work and takes a lot of time and patience.
>>
>>My proposal (that the board accepted) to move gump to top level status 
>>was also to bring more visibility and make projects being more 
>>gump-friendly, we'll see how this goes.
>>
>>I have a RT ready for gump that would allow to solve these issues... but 
>>I need to work more on this since it appears to be a pretty tough 
>>computational problem of graph analysis.
> 
> 
> But this is much more than I want to solve with it at the moment. I just want to
> replace the jars.xml with the gump.xml. We still can have our "check jars" so
> that we are nagged if gump is broken (at least for this issue). At least we
> avoid the duplicate maintenance of jars.xml and gump.xml that exists at the
> moment. One day Cocoon and Gump nicely plays together again, we can give all to
> Gump and remove our specific checking stuff. Short steps towards a big aim :)
> 
> WDYT?

+1

my thinking are just more gump related than cocoon-related anyway... 
besides, the more I work with graphs the more I see graphs everywhere so 
beware :-)

-- 
Stefano.


Re: Gump

Posted by Joerg Heinicke <jo...@gmx.de>.
Stefano Mazzocchi <stefano <at> apache.org> writes:

> > ... gump as complete replacement for jars.xml ...

> > Is our gump descriptor that bad maintained? Some time ago we also got 
> > gump error messages to the list, now we get those only from persons 
> > outside of Cocoon. What's the benefit of gump when we don't use it 
> > correctly?
> 
> Gump has not been able to run cocoon for the last 6 months at least, due 
> to unmet dependencies. As a result, our decriptor is basically dead 
> because we haven't been nagged for that period of time.
> 
> The gump community is working hard to make this possible again, but this 
> is very hard work and takes a lot of time and patience.
> 
> My proposal (that the board accepted) to move gump to top level status 
> was also to bring more visibility and make projects being more 
> gump-friendly, we'll see how this goes.
> 
> I have a RT ready for gump that would allow to solve these issues... but 
> I need to work more on this since it appears to be a pretty tough 
> computational problem of graph analysis.

But this is much more than I want to solve with it at the moment. I just want to
replace the jars.xml with the gump.xml. We still can have our "check jars" so
that we are nagged if gump is broken (at least for this issue). At least we
avoid the duplicate maintenance of jars.xml and gump.xml that exists at the
moment. One day Cocoon and Gump nicely plays together again, we can give all to
Gump and remove our specific checking stuff. Short steps towards a big aim :)

WDYT?

Joerg

PS: Arrgghh! This nasty gmane.org: "You seem to be top-posting. Don't do that."
I only had "... gump ..." without any >> infront.