ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <ddevie...@gmail.com>
Subject Re: Target enablement via nested conditions?
Date Thu, 23 Apr 2009 15:20:47 GMT
On Thu, Apr 23, 2009 at 8:13 AM, Jeffrey E Care <carej@us.ibm.com> wrote:
> Off and on we've discussed more robust ways of determining target
> enablement, such as adding some type of EL syntax to if/unless.
>
> It dawned on me yesterday that we might already have the makings of a very
> robust system: why not use conditions nested in targets to determine if the
> target is enabled? I think effectively this is what people do already by
> having the "real" target depend on a "decision" target that sets (or
> doesn't) the controlling property used in the if attribute of the real
> target.
>
> We can quibble on the schema, but here's an example to illustrate the point:
>
> <target name="doSomeWork">
>   <target-enabled>
>     <and>
>       <istrue value="${controlling.property.1}"/>
>      <istrue value="${controlling.property.2}"/>
>     </and>
>   </target-enabled>
>
>   <!-- real work starts here -->
> </target>
>
> Thoughts?

Sounds like all we need is a <return/> "task" then ;-)

<ac:if> ... <ac:then> <return/> </ac:then> </ac:if>

More seriously, <target-enabled> sounds like a good idea, it's more
declarative, albeit a little heavy syntax wise (but then isn't Ant
heavy syntax wise ;-).

And advantage of doing it like this is that it's more obvious that
it's "evaluated" *after* the dependent targets, unlike the if/unless
attribute syntax (a common new user mistake is to assume if/unless are
evaluated before dependent targets are "run").

As long as <target-enabled> is restricted as the first child of
<target> only. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message