ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stephan beal <>
Subject Re: reg: cvs / clearcase task
Date Wed, 27 Mar 2002 12:03:05 GMT
On Wednesday 27 March 2002 12:17 pm, Diane wrote:
> --- stephan beal <> wrote:
> > On Tuesday 26 March 2002 22:25 pm, Diane Holt wrote:
> > > But 'cvs log' does give you a return code of 1. And 'cvs diff'
> > > returns 0 for no diffs, 1 for diffs. So it's all doable using
> > > currently available Ant tasks.
> >
> > Nope. How does the user get the return code for cvs without actually
> > coding a task with it's one Execute/Commandline objects? He can't get
> > it via the Cvs  task object [...]
> I didn't say "it's all doable using the Cvs task" -- I said "it's all
> doable using currently available Ant tasks".  

You cannot get the error code of a run program using any current (1.4x) Ant 
task without hacking that task. If i am wrong, please show me, because i 
would Love to know how to do it.

> The guy wanted to know if
> there was way to do what he wants to do -- I assume without having to
> write his own task(s) or modify existing ones -- and, yes, there is.

As you pointed out, he could do a <foreach> and <condition> loop, but he 
cannot get the error codes, so he can't use those as conditions. 
However, there are a lot of things you can't programmatically know about a 
cvs repository until you run a cvs command, and then you can't 
half-accurately know what happened because you can get no error code from Ant.
Perhaps i'm misunderstanding what he wanted to do.

(from an earlier mail)
> But 'cvs log' does give you a return code of 1. And 'cvs diff' returns 0
> for no diffs, 1 for diffs. So it's all doable using currently available
> Ant tasks.

It cannot be done with the supplied Ant tasks, using them as-is, because you 
can't get the return values of the executed command. A cvs log will kill your 
build if failonerror is true (poor usage of error codes in cvs, imo).

> You seem awfully quick to make pronouncements that Ant can't do X unless
> you start hacking at the code -- and that's just not actually been the
> case 99.9% of the time. 

i generally am quick to say, "it Could be hacked to do this." i think the 
case of the PatternSet.set{In,Ex}cludes() is the only time i've said that it 
cannot be done without hacking. As a hacker, my preference is simply for 
hacking ;).

> > 'cvs --help diff' also returns 1,
> Yeah, so? -- who said anything about running 'cvs --help diff'??

i was just pointing out that cvs returns non-0 error codes in some silly 
places, as in the case of 'cvs diff' (IMO, it should return non-0 only on 
failure, as in the case of other C-based app out there.)

> The ant-user list is a place where people can ask for solutions to their
> problems, and hopefully we can offer them some. Constantly poohpoohing
> those proffered solutions that use what's already available seems awfully
> counterproductive -- especially since it's more often than not
> misinformation to say you can't do this or that, since in fact you can.

i'm sorry if you feel i was denouncing your solution. i was attempting to 
clarify the point that things involving error codes cannot be done using 
as-supplied tasks (not even <exec> gives you the return value anywhere).

> I don't always put the solution together in actual Ant format (and I
> didn't this time because, frankly, I had a bit too much brew and Thirsty
> Bear last night to feel like doing much of anything today :), but trust me
> on this, if I say there's a way to do it, it means I have actually thought
> of how -- I just haven't necessarily typed it all out.

And you have shown this to be true, i'll be the first to admit (behind 
Dominique, perhaps ;). i'm extremely sorry that i've come across as 
denouncing what you've said, but the statement "can be done with current Ant 
tasks" is not true unless you extend that to mean "can be done with [hacked] 
current Ant tasks." i would be more than happy to be wrong on this, of 
course, because i've also needed this functionality.

----- stephan
Generic Unix Computer Guy -
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message