ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <>
Subject RE: [PROPOSE] task parameters that are only supplied when a property is defined
Date Sat, 09 Mar 2002 14:27:40 GMT
Bill -

Uh, you're right, and I am embarrassed to say that I am the author of the <stcheckout>
task and I did not even remember my own code.  I didn't think you were and looked at the code
to disprove your suggestion but found you were correct.

So I could get the behavior I want by defining in the buildxml blank properties for every
label I may want to define, and then via -D or a properties file I could optionally define
those properties with a real label.

That would work and it would not be too ugly.  It will be my interim solution.

However, I still agree with you that something like the Quiet Notation you describe would
be an even better way to handle this.  To reiterate the point,
Costin listed five different ways of handling the case of an undefined property in a task

 1) throw exception
 2) replace it with ""
 3) leave it unchanged ( current solution )
 4) don't set the property at all ( similar with what this proposal)
 5) insert 'null' - the original implementation ( in whatever version
 we had in 99 :-)

The point is that none of these will be correct in all use cases, but since a default must
be chosen (#3 in this case),  then there should be syntactical ways for the build-script writer
to indicate each of the other four behaviors as the way to handle a missing property, on a
per-use basis. 

I would like a solution like this because it gives the most freedom to the build-script writer
while making it explicit from the script itself what is going on.

I am less enamoured of solutions implemented in the java code or plug-ins because they are
further from the build script writer.  Yes, we developers can look at the source code, but
Ant has a wider audience than java programmers.  Even though I can look at and even change
the java code of a task, when I am diddling with a script, that isn't something I want to
do.  If I as the author of a task can't remember how it works, what chance does the mere user
have?  I'd much rather be able to implement what I want via the script.


-----Original Message-----
From: Bill Burton []
Sent: Fri 3/8/2002 11:08 PM
To: Ant Developers List
Subject: Re: [PROPOSE] task parameters that are only supplied when a property is defined

Hello Steve,

Here's a solution for <stcheckout> currently in CVS.  

Try calling <stcheckout> with a blank label, i.e. label="".  You should
find it ignores a blank label. Assuming that works, all you have to do is
specify the lbl property as blank:
    <property name="lbl" value="" />

Then, if you want to use a label, either specify it to Ant as
-Dlbl=labelName or use <properties file> to load a file of properties
where lbl is defined to some value.  This would have to be specified
before the default blank value is set.

You can use this technique for any attribute that ignores a blank value.

The Quiet Notation syntax would work in this case as well.  But the above
solution is nearly as easy to use and works today.


Steve Cohen wrote:
> I previously sent this idea in a message whose title may have hidden its importance,
but this is an idea I'd really like to see and I'd like the developers to comment on it.
> What if there were a convenient syntax within ant for specifying task attributes based
on properties
> such that
> if the property were not set
>         the task code would never see the attribute?
> In other words, for example, look at this call:
>   <stcheckout URL="STARTEAM:49201/Aproject/AView"
>      username="auser"
>      password="secret"
>      rootlocalfolder="C:\dev\buildtest\co"
>      forced="true"
>      label = "${lbl}"
>   />
> If the lbl property is defined, the task will get its value as the label attribute. 
But if the lbl property is not defined, the task will get the text "${lbl}" and most likely
> I am proposing a new syntax that would allow a property to be specified with a different
meaning.  Let's say this syntax is two dollar signs instead of one ($${property}).  (This
may not be the optimal symbol for the ant parser, but that is a detail - I am not wedded to
any symbol).
> Using this syntax, the above example becomes:
>   <stcheckout URL="STARTEAM:49201/Aproject/AView"
>      username="auser"
>      password="secret"
>      rootlocalfolder="C:\dev\buildtest\co"
>      forced="true"
>      label = "$${lbl}"
>   />
> My proposal is that this syntax be interpreted this way:
> If the property lbl is defined, treat $${lbl} exactly as ${lbl} but
> if the property lbl is not defined, do not even pass the label attribute to the task.
> It seems to me that this would allow for much more flexible scripts, especially when
more than one parameter of a task is optional and there are different use cases for the task.
 In the above example, to get the variable functionality desired, I must include two blocks
in my script, one with the label attribute defined and the other without it, and put it some
conditionals to direct the processing to the right place.  This can get clumsy, especially
if there are several attributes to parameterize; the combinatorial possiblilities could be
large, making for scripts that are harder to understand or maintain.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message