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/01 07:02:57 UTC
Re: Licenses of Libraries [was Re: cvs commit: cocoon-2.1/src/blocks/html/lib
jtidy-04aug2000r7-dev.jar.license]
Geoff Howard wrote:
> What about just adding an element for licence location to jars.xml? e.g.,
>
> <<file>
> <title>Avalon Excalibur DataSource</title>
> <description>Part of avalon, it is a set of classes and patterns
> that support high level server development.</description>
> <used-by>Cocoon</used-by>
> <lib>databases/lib/excalibur-datasource-1.1.1.jar</lib>
> <homepage>http://avalon.apache.org/excalibur/</homepage>
> <license>legal/LICENSE.avalon</license>
> </file>
Gump descriptors now contain license information and gump is checking it
for you. I think we should use that.
--
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.
Re: Gump
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Gump (was: Licenses of Libraries)
Posted by Joerg Heinicke <jo...@gmx.de>.
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?
Joerg
RE: Licenses of Libraries [was Re: cvs commit: cocoon-2.1/src/blocks/html/lib jtidy-04aug2000r7-dev.jar.license]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Geoff Howard wrote:
>
> What about just adding an element for licence location to
jars.xml?
> e.g.,
>
> <<file>
> <title>Avalon Excalibur DataSource</title>
> <description>Part of avalon, it is a set of classes and
> patterns that support high level server development.</description>
> <used-by>Cocoon</used-by>
> <lib>databases/lib/excalibur-datasource-1.1.1.jar</lib>
> <homepage>http://avalon.apache.org/excalibur/</homepage>
> <license>legal/LICENSE.avalon</license>
> </file>
>
Sounds ok for me, but please keep in mind that there can be more
than one license per project. E.g. Avalon uses in some subprojects
the old license and in some the new 2.0 license.
Carsten