ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remie Bolte <re...@backbase.com>
Subject Re: Target enablement via nested conditions?
Date Thu, 23 Apr 2009 21:27:42 GMT
My 2 cents:
I think it makes the structure more clear. Personally I do not like the (in
my opinion) bogus targets only for evaluating if a target should be executed
or not. I can see the principle design argument, but it feels like they
bloat my ant scripts and make them less easy to understand. My main goal is
to concentrate logic where it is applicable as much as possible.

I would suggest not to use a new task (target-enabled) but simply stick with
the condition task:

<target name="my-next-task">
  <condition>
    <available file="output-of-previous-task" />
  </condition>
  <!-- do my stuff -->
</target>

cheers,

Remie


On Thu, Apr 23, 2009 at 5:20 PM, Dominique Devienne <ddevienne@gmail.com>wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message