ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Longman <cra...@begeek.com>
Subject suggestions
Date Thu, 20 Sep 2001 16:33:30 GMT

i've only very recently really started looking at the build process in
ant, and have some observations that i have found might have been useful
for me.  i would like to post them here and get some feedback before i
investigate any further.

1) it seems like some way of quickly comparing a property to some value
would be helpful.  as an '=' is almost certainly never going to be a
valid character in a property, this kind of thing should work pretty
well:
  <target name="target" if="some.property=hello"/>
  <target name="target" if="some.property=goodbye"/>

as just a simple way of combining a simple comparison.  this will let
the build file set one property to contain different values, depending
on what needs to be done.  it seems the general feeling in ant is that
different property names are better, but i still find that using a
property name pointing to a value that indicates whats going on is the
right thing sometimes (like jdbc.driver=pgsql, rather than
jdbc.driver.pgsql=true for eg).

2) something that calls one or more targets AFTER a target has
completed.  for example, in my init target, i often have properties that
i need to conditionally set, and currently the only way to easily do
that is multiple targets with 'if' attributes.  but, i would still want
to ensure that the init is completed first, while still ensuring that
the other conditional-inits are completed immediately following the init
target.

3) some way to silence a target.  i've been using simple 'check' targets
frequently, to ensure that the buildfile is only called with the correct
targets and not called to execute an internal only target for eg.  but,
this means that there are multiple 'check-XXX' listed in the output that
do nothing other than clutter it up.  it would be nice if we could
indicate that a target not announce that it is running, or perhaps only
announce itself if it actually runs, so if the conditions that the
target depends on fail, then nothing gets printed out.

4) some way to indicate that a target is to be only called from the
build file itself, not externally.  this is basically what i'm trying to
simulate in 3), but being able to code it directly in the build file
might be helpful.

that's all i can think of right now.  anyone got any comments or
suggestions for these?

cheers,

     CraigL->Thx();



Mime
View raw message