Thus spake Leo Simons ([EMAIL PROTECTED]):
I found
http://www.nullcube.com/software/pylid.html
while looking for a usable code coverage tool and test
runner. It's much better than what we (Gump [1]) had (we
used testrunner.py from Zope which is a real ugly script
which I made uglier
Does anyone ever do anything with the content of these messages?
Yes, I look for module failures and even worse for module success but
with warnings. The later usually means stuff has been moved in svn,
we are now unable to check it out, but Gump doesn't consider it a
failure.
Stefan
On Fri, 24 Jun 2005, Simon Kitching [EMAIL PROTECTED] wrote:
commons-logging now depends on both:
* logging-log4j 1.2.x as ${log4j12.jar}, and
* logging-log4j 1.3 (currently at alpha-6) as ${log4j13.jar}
easy to fix since Gump builds both branches. I'll take care of it.
Stefan
On Fri, 24 Jun 2005, Simon Kitching [EMAIL PROTECTED] wrote:
By the way, the jars generated by the ant build.xml file also now
have a version number in them,
yes, but Gump can (and will) override it using the component.version
property.
Stefan
Dear Gumpmeisters,
The following 7 notifys should have been sent
*** G U M P
[EMAIL PROTECTED]: Module castor success, but with warnings.
[EMAIL PROTECTED]: Project nant (in module nant) failed
[EMAIL PROTECTED]: Module jaxen
Dear Gumpmeisters,
The following 7 notifys should have been sent
*** G U M P
[EMAIL PROTECTED]: Module castor success, but with warnings.
[EMAIL PROTECTED]: Project nant (in module nant) failed
[EMAIL PROTECTED]: Module jaxen
On Fri, 2005-06-24 at 08:43 +0200, Stefan Bodewig wrote:
On Fri, 24 Jun 2005, Simon Kitching [EMAIL PROTECTED] wrote:
commons-logging now depends on both:
* logging-log4j 1.2.x as ${log4j12.jar}, and
* logging-log4j 1.3 (currently at alpha-6) as ${log4j13.jar}
easy to fix since Gump
Does anyone ever do anything with the content of these messages?
Yes, I look for module failures and even worse for module success but
with warnings. The later usually means stuff has been moved in svn,
we are now unable to check it out, but Gump doesn't consider it a
failure.
Want
On Fri, 24 Jun 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote:
Yes, I look for module failures and even worse for module success
but with warnings. The later usually means stuff has been moved
in svn, we are now unable to check it out, but Gump doesn't
consider it a failure.
Want this to
On Fri, 24 Jun 2005, [EMAIL PROTECTED] wrote:
SCM update failure a module failure (even if we have a stale copy.)
Cool thanks.
The commit itself made me itch to spend more time on Python, the exact
same code-change in three different files.
Well, there are at least four proprietary MS
The commit itself made me itch to spend more time on Python, the exact
same code-change in three different files.
Yeah, bad copy-n-paste on my part (ok, 1 of the 2 copies). The more I look
at Gump2 these days, the more I feel I need to spend time on Gump3 see if
I can do Python right these
Folks,
Somebody (not me) seems to have most/all of a test Gump install on our
solaris zone. Thanks!!!
I simply (after some poking around) had to re-create /var/run/apache2 and
start the HTTPD, and we get these pages.
I've just kicked off a test run.
Gump crashes when listing
--
Key: GUMP-140
URL: http://issues.apache.org/jira/browse/GUMP-140
Project: Gump
Type: Bug
Components: Python-based Gump
Versions: Gump2-2.3
Environment: Solaris (likely all)
Reporter: Adam Jack
13 matches
Mail list logo
