ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject Re: using multiple properties in the 'if' and 'unless' conditions
Date Fri, 23 Jun 2006 14:07:40 GMT
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) {

'bshif' accepts an arbitrary BSH expression (or statements), as shown
in a different form below.

<?xml version="1.0"?>

<!DOCTYPE project [
  <!ENTITY and "&amp;&amp;">
  <!ENTITY or "||">
  <!ENTITY ge "&gt;=">
  <!ENTITY le "&lt;=">

<project name="BshConditionTest" default="tearDown"

  <target name="setUp" />
  <target name="tearDown" />

  <target name="test-true">

    <condition property="value">


  <target name="test-string-equals">

    <property name="p1" value="toto" />
    <property name="p2" value="titi" />

    <condition property="equals">


  <target name="test-starts-with">

    <property name="p1" value="toto" />
    <property name="p2" value="titi" />

    <condition property="startsWith1">

    <condition property="startsWith1a">

    <condition property="startsWith2">

    <condition property="startsWith2a">

    <condition property="startsWith3">
      <bsh:condition>"${p1}".startsWith("t") &and;
    <condition property="startsWith3a">
      <bsh:condition>p1 = "${p1}".startsWith("t");
                     p2 = "${p2}".startsWith("t");
                     p1 &and; p2;</bsh:condition>

    <condition property="startsWith4">
      <bsh:condition>"${p1}".startsWith("ti") &and;
    <condition property="startsWith4a">
      <bsh:condition>p1 = "${p1}".startsWith("ti");
                     p2 = "${p2}".startsWith("ti");
                     p1 &and; p2;</bsh:condition>

    <condition property="startsWith5">
      <bsh:condition>"${p1}".startsWith("ti") ||
    <condition property="startsWith5a">
      <bsh:condition>p1 = "${p1}".startsWith("ti");
                     p2 = "${p2}".startsWith("ti");
                     p1 &or; p2;</bsh:condition>


On 6/23/06, Riedel Thomas (KSFD 121) <> 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 []
> 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:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message