I'm a bit concerned about your usage of Ant, really, because when the
build begins to be than conditional, it's a bad 'smell' to me, or if
you prefer a tale-tell sign than a different approach might be
warranted. Note that I'm not trying to insult you in any way,
everyone's free to use or abuse Ant any way they like, but that's my
personal opinion. There are many ways to achieve a goal generally, and
some are more descriptive than others.
That said, for my own scripts, I did use a custom <if>-like task (with
no <else> though) which accepted a bshif attribute, which was useful
in some rare circumstances, and then only as a short-cut, to avoid
writing custom Java tasks. I used these only for one-off things, and
would have made proper tasks for more general purpose usage.
I would be +1 to allow adding custom attributes to <target>, like used
to be supported by Mutant I believe. Thus giving you the opportunity
to plug your own arbitrarily-complex logic there to supplement the
very basic if/unless. --DD
/**
* Sets a BeanShell 2 boolean expression which <strong>must</strong>
* evaluate to <code>true</code> for this aspect to be active.
*
* @param bshCondition the boolean expression.
*/
public void setBshIf(String bshCondition) {
_conditionals.setBshIf(bshCondition);
}
'bshif' accepts an arbitrary BSH expression (or statements), as shown
in a different form below.
<?xml version="1.0"?>
<!DOCTYPE project [
<!ENTITY and "&&">
<!ENTITY or "||">
<!ENTITY ge ">=">
<!ENTITY le "<=">
]>
<project name="BshConditionTest" default="tearDown"
xmlns:bsh="antlib:buildmagic.bsh">
<target name="setUp" />
<target name="tearDown" />
<target name="test-true">
<condition property="value">
<bsh:condition>true</bsh:condition>
</condition>
</target>
<target name="test-string-equals">
<property name="p1" value="toto" />
<property name="p2" value="titi" />
<condition property="equals">
<bsh:condition>"${p1}".equals("${p2}")</bsh:condition>
</condition>
</target>
<target name="test-starts-with">
<property name="p1" value="toto" />
<property name="p2" value="titi" />
<condition property="startsWith1">
<bsh:condition>"${p1}".startsWith("t")</bsh:condition>
</condition>
<condition property="startsWith1a">
<bsh:condition>"${p1}".startsWith("ti")</bsh:condition>
</condition>
<condition property="startsWith2">
<bsh:condition>"${p2}".startsWith("t")</bsh:condition>
</condition>
<condition property="startsWith2a">
<bsh:condition>"${p2}".startsWith("ti")</bsh:condition>
</condition>
<condition property="startsWith3">
<bsh:condition>"${p1}".startsWith("t") ∧
"${p2}".startsWith("t")</bsh:condition>
</condition>
<condition property="startsWith3a">
<bsh:condition>p1 = "${p1}".startsWith("t");
p2 = "${p2}".startsWith("t");
p1 ∧ p2;</bsh:condition>
</condition>
<condition property="startsWith4">
<bsh:condition>"${p1}".startsWith("ti") ∧
"${p2}".startsWith("ti")</bsh:condition>
</condition>
<condition property="startsWith4a">
<bsh:condition>p1 = "${p1}".startsWith("ti");
p2 = "${p2}".startsWith("ti");
p1 ∧ p2;</bsh:condition>
</condition>
<condition property="startsWith5">
<bsh:condition>"${p1}".startsWith("ti") ||
"${p2}".startsWith("ti")</bsh:condition>
</condition>
<condition property="startsWith5a">
<bsh:condition>p1 = "${p1}".startsWith("ti");
p2 = "${p2}".startsWith("ti");
p1 ∨ p2;</bsh:condition>
</condition>
</target>
</project>
On 6/23/06, Riedel Thomas (KSFD 121) <[EMAIL PROTECTED]> wrote:
Yes I agree the kind of our Ant-usage might be a bit beyond horizon. We
are doing continious integration for a 5 Mio LOC project, generic
automated junit testing, automatic deploying into a production like
server pool, online testing, web-testing, automated metrics generation
for the architecture group, automated baseline quality level assertion,
messaging, etc.etc and all this with ant, quite error prove ;) The main
problem is that not every error or event might break the build - instead
we have different level of build quality. So the flow of the different
steps (targets) is very dynamic. We are in copious use of <if>,
<trycatch> and all the other nice contrib tasks that make ant more a
script language than an descriptive build tool.
The other possiblity for a bit more dynamic flow of control would be a
dynamic condition, I guess. In the sense that the evaluation of the
condition should not be done once when the task is executed but every
time somebody references that condition. But thats just a guess.
-----Original Message-----
From: Steve Loughran [mailto:[EMAIL PROTECTED]
Sent: Friday, June 23, 2006 1:08 PM
To: Ant Developers List
Subject: Re: using multiple properties in the 'if' and 'unless'
conditions
Riedel Thomas (KSFD 121) wrote:
> We have written a large library of own very sophisticated ant tasks
for
> all the high level stuff. What I am thinking is that especially for
the
> work-flow control it would be great to steer the flow between
different
> targets via complex if-statements. I see the point that Ant should be
> easy and descriptive, but a (somehow implemented) flow control would
> make life easier (for the integration team ;))
>
>
hey, we're trying to be a build tool, not a generic workflow system.
What is your project trying to do?
And are you using ant-contrib's <if> and <try><catch> tasks?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
