You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Leo Simons <le...@apache.org> on 2003/12/02 21:44:52 UTC
[RT] linking to CVS & other intelligent features
Hi gang!
I think it would be great if gump would parse the output of builds,
adding links to ViewCVS for problematic files. For example, with Batik
failing (http://gump.covalent.net/log/xml-batik.html), the problem is
compiling a class, and the problem looks like this:
[javac]
/data/gump/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java:69:
org.apache.batik.script.rhino.BatikSecurityController should be declared
abstract; it does not define
callWithDomain(java.lang.Object,org.mozilla.javascript.Context,org.mozilla.javascript.Callable,org.mozilla.javascript.Scriptable,org.mozilla.javascript.Scriptable,java.lang.Object[])
in org.mozilla.javascript.SecurityController
[javac] public class BatikSecurityController extends SecurityController {
from this, it should be possible to make BatikSecurityController.java
into a link to
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java.
In fact, even more intelligence might be possible. We could perhaps have
something like
---
The continuous integration build for xml-batik has failed! It has been
doing so for 234 days in a row now. See
http://gump.apache.org/20040505/build_xml-batik.html
for a full report. If you wish, you can try to fix the problem in CVS,
then immediately rerun the continous integration build here:
http://gump.apache.org/interactive/xml-batik
to see if you've fixed the problem. Gump's best guess as to the cause
of the failure...it seems to be a failure to compile this source file:
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java
The cvs log for the file looks like this:
RCS file:
/home/cvspublic/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java,v
Working file:
sources/org/apache/batik/script/rhino/BatikSecurityController.java
head: 1.3
branch:
locks: strict
access list:
symbolic names:
batik-1_5: 1.2
batik-1_5beta5: 1.1
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
----------------------------
revision 1.3
date: 2003/08/08 11:39:20; author: vhardy; state: Exp; lines: +50 -8
Updated header files in source code to show the new standard Apache
source header
----------------------------
revision 1.2
date: 2003/04/11 13:58:58; author: vhardy; state: Exp; lines: +2 -7
import statements clean up, thanks to Vladimir Bossicard's contribution.
Now only have explicit imports (removed a few * imports. Removed unused
imports. Imports now sorted in alphabetical order. Also, converted the
few windows files to UNIX style
----------------------------
revision 1.1
date: 2003/03/14 11:15:52; author: cjolif; state: Exp;
replacement for BatikSecuritySupport and EventTargetWrapHandler for new
APIs introduced in Rhino15R4.
=============================================================================
The full build log follows below:
<snip/>
---
We could even go nuts and include a Clippy animation 8-)
cheers!
- LSD
Re: [RT] linking to CVS & other intelligent features
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 2 Dec 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> Leo Simons" <leosimons@apache.org: wrote:
>> http://ant.apache.org/manual/listeners.html
>
> Yup, I knew they exists .. but not if they made it easier. ;-)
Depends on the compiler. If compilation errors go to a different
stream than warnings (and normal output), you'll get results with
different log levels.
> Hmm, how do IDEs and such do these things?
regular expressions working on stdout/err. This here is what I use in
my .xemacs/init.el (indirectly):
(setq compilation-error-regexp-alist
(append (list
;; works for jikes
'("^\\s-*\\[[^]]*\\]\\s-*\\(.+\\):\\([0-9]+\\):\\([0-9]+\\):[0-9]+:[0-9]+:" 1 2 3)
;; works for checkstyle
'("^\\s-*\\[[^]]*\\]\\s-*\\(.+\\):\\([0-9]+\\):\\([0-9]+\\):" 1 2 3)
;; works for javac
;; thanks to Barrie Treloar <Ba...@camtech.com.au>
'("^\\s-*\\[[^]]*\\]\\s-*\\(.+\\):\\([0-9]+\\):" 1 2))
compilation-error-regexp-alist))
for the combination of XEmacs, JDEE and Ant. These regexpes should
work for the standard logger and could be translated to Python rather
easily, I guess.
Match 1 is the filename and 2 the line number (3, if present, the
column).
Stefan
Re: [RT] linking to CVS & other intelligent features
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 03 Dec 2003, Nick Chalko <ni...@chalko.com> wrote:
> Can ant output to BOTH the console and a xml log. No need to run
> twice.
Yep, register XmlLogger as -listener.
Stefan
Re: [RT] linking to CVS & other intelligent features
Posted by Nick Chalko <ni...@chalko.com>.
Adam R. B. Jack wrote:
>Leo Simons" <leosimons@apache.org: wrote:
>
>
>
>>>A question for Ant Gurus ... is there any form of XML log formatter, or
>>>event listener, that we could use to make this task easier on Gump? Some
>>>form of structured output as well as the human readable stuff?
>>>
>>>
>>I know that one!
>>
>>http://ant.apache.org/manual/listeners.html
>>
>>
>
>Yup, I knew they exists .. but not if they made it easier. ;-)
>
>What say we take any build that fails, re-run it (no new CVS update) with
>the xml logger, then try to parse the xml log file. For clues. I suspect
>that the issue is still digging a classname/compile error out of some
>string, I doubt the XML logger can know compiler specific tags or anything.
>
>
>
Can ant output to BOTH the console and a xml log. No need to run twice.
>Hmm, how do IDEs and such do these things? Eclipse surely parses the text
>output, maybe 'stderr'.
>
>regards
>
>Adam
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>
>
Re: [RT] linking to CVS & other intelligent features
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
Leo Simons" <leosimons@apache.org: wrote:
> > A question for Ant Gurus ... is there any form of XML log formatter, or
> > event listener, that we could use to make this task easier on Gump? Some
> > form of structured output as well as the human readable stuff?
> I know that one!
>
> http://ant.apache.org/manual/listeners.html
Yup, I knew they exists .. but not if they made it easier. ;-)
What say we take any build that fails, re-run it (no new CVS update) with
the xml logger, then try to parse the xml log file. For clues. I suspect
that the issue is still digging a classname/compile error out of some
string, I doubt the XML logger can know compiler specific tags or anything.
Hmm, how do IDEs and such do these things? Eclipse surely parses the text
output, maybe 'stderr'.
regards
Adam
Re: [RT] linking to CVS & other intelligent features
Posted by Leo Simons <le...@apache.org>.
Adam R. B. Jack wrote:
> A question for Ant Gurus ... is there any form of XML log formatter, or
> event listener, that we could use to make this task easier on Gump? Some
> form of structured output as well as the human readable stuff?
I know that one!
http://ant.apache.org/manual/listeners.html
- LSD
Re: [RT] linking to CVS & other intelligent features
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
Interesting idea.
I've always hated how a break in project X interface gets reported/nagged to
dependent project Y, and wished I could 'get inside the problem' and detect
who was at fault. [If Y didn't change [we check this as we extract from w/
CVS/SVN] maybe don't blame Y, but how track down X?] Not exactly what you
were saying, but another 'intelligent' feature.
A question for Ant Gurus ... is there any form of XML log formatter, or
event listener, that we could use to make this task easier on Gump? Some
form of structured output as well as the human readable stuff?
regards
Adam
----- Original Message -----
From: "Leo Simons" <le...@apache.org>
To: <gu...@jakarta.apache.org>
Sent: Tuesday, December 02, 2003 1:44 PM
Subject: [RT] linking to CVS & other intelligent features
> Hi gang!
>
> I think it would be great if gump would parse the output of builds,
> adding links to ViewCVS for problematic files. For example, with Batik
> failing (http://gump.covalent.net/log/xml-batik.html), the problem is
> compiling a class, and the problem looks like this:
>
> [javac]
>
/data/gump/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityCont
roller.java:69:
> org.apache.batik.script.rhino.BatikSecurityController should be declared
> abstract; it does not define
>
callWithDomain(java.lang.Object,org.mozilla.javascript.Context,org.mozilla.j
avascript.Callable,org.mozilla.javascript.Scriptable,org.mozilla.javascript.
Scriptable,java.lang.Object[])
> in org.mozilla.javascript.SecurityController
> [javac] public class BatikSecurityController extends SecurityController {
>
> from this, it should be possible to make BatikSecurityController.java
> into a link to
>
>
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java.
>
>
> In fact, even more intelligence might be possible. We could perhaps have
> something like
>
> ---
> The continuous integration build for xml-batik has failed! It has been
> doing so for 234 days in a row now. See
>
> http://gump.apache.org/20040505/build_xml-batik.html
>
> for a full report. If you wish, you can try to fix the problem in CVS,
> then immediately rerun the continous integration build here:
>
> http://gump.apache.org/interactive/xml-batik
>
> to see if you've fixed the problem. Gump's best guess as to the cause
> of the failure...it seems to be a failure to compile this source file:
>
>
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java
>
> The cvs log for the file looks like this:
>
> RCS file:
>
/home/cvspublic/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurit
yController.java,v
> Working file:
> sources/org/apache/batik/script/rhino/BatikSecurityController.java
> head: 1.3
> branch:
> locks: strict
> access list:
> symbolic names:
> batik-1_5: 1.2
> batik-1_5beta5: 1.1
> keyword substitution: kv
> total revisions: 3; selected revisions: 3
> description:
> ----------------------------
> revision 1.3
> date: 2003/08/08 11:39:20; author: vhardy; state: Exp; lines: +50 -8
> Updated header files in source code to show the new standard Apache
> source header
> ----------------------------
> revision 1.2
> date: 2003/04/11 13:58:58; author: vhardy; state: Exp; lines: +2 -7
> import statements clean up, thanks to Vladimir Bossicard's contribution.
> Now only have explicit imports (removed a few * imports. Removed unused
> imports. Imports now sorted in alphabetical order. Also, converted the
> few windows files to UNIX style
> ----------------------------
> revision 1.1
> date: 2003/03/14 11:15:52; author: cjolif; state: Exp;
> replacement for BatikSecuritySupport and EventTargetWrapHandler for new
> APIs introduced in Rhino15R4.
>
============================================================================
=
>
> The full build log follows below:
>
> <snip/>
> ---
>
> We could even go nuts and include a Clippy animation 8-)
>
> cheers!
>
> - LSD
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: gump-help@jakarta.apache.org
>