On Wed, 28 Nov 2001, Denis Hennessy <[EMAIL PROTECTED]> wrote:
> The idea with waitfor is that there's a set of sub-elements that
> define the conditions you are waiting for.
Yet another idea - make that conditions implement Condition and your
task extend ConditionBase.
This way <condition> could check for the existance of documents or
whether something is listening on a given socket - in turn, you could
drop your <file> condition in favour of <available> and gain access to
<not> (don't know whether the other built-in conditions would be
useful as well). This would also make the ANDing of conditions you
perform explicit, which is a good thing IMHO.
Something like
<waitfor>
<not>
<socket ... />
</not>
</waitfor>
which would test whether a server has been shutdown.
Basically <waitfor> really is a <condition> wrapped into a loop that
spins until the condition gets true, isn't it?
You'd have something like
protected class WaitForCondition implements WaitForEvent {
boolean hasPassed = false;
Condition c = null;
public void setCondition(Condition c) {
this.c = c;
}
public boolean isReady() {
if (hasPassed) {
return true;
}
if (c == null) {
throw new BuildException("No condition specified");
}
if (c.eval()) {
hasPassed = true;
return true;
} else {
return false;
}
}
}
and would implement the logic inside the conditions instead of the
WaitForEvent implementations.
Stefan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
