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 propertyis defined
Date Fri, 08 Mar 2002 22:01:38 GMT
Thanks for responding.  I had a feeling that you guys must have debated
this issue sometime in the past and knowing the history does help.

Based on your input, I think I can (and will) rewrite <stcheckout> to
check for "$<".  And yet, I wonder if it's such a good thing that each
task handles this differently.  Wouldn't this make it more confusing for
the user?

I will have to take a look at the ProjectHelper and



-----Original Message-----
From: []
Sent: Friday, March 08, 2002 3:47 PM
To: Ant Developers List
Subject: RE: [PROPOSE] task parameters that are only supplied when a
propertyis defined

On Fri, 8 Mar 2002, Steve Cohen wrote:

> Well, I'm not a committer either.  I think we're on the same page and
> hope a committer will chime in here.  I could implement something like

> this in the task that I developed for ant, but that is the wrong 
> approach, it should go in the core.

The question is what to do if a property is not defined in a ${name}.
There are few solutions:
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 current solution has the benefit that it gives a chance to the 
task to recover or do something usefull - no information is lost.
It is trivial to check indexOf( "${" ), and validating your input
data is usually a good idea.

You can then do your own replacement if you want, using a different
property repository. In reality no task is doing that - so it can be 
argued that 1) may have been a better choice ( or not ). 
I think the behavior of properties should remain unchanged, at least
for backward compatibilty ( and I actually prefer this solution 
since it gives more flexibility to recover ). 

Adding a new syntax to change the behavior of unset properties is 
not the best idea - what next, have a separate syntax for each behavior
that may be usefull for some use ?

I would be ok with a setting in project to direct this behavior,
and I am ok with a new syntax for modifiable properties ( one 
very requested feature ). 

However both could be implemented by using better hooks in the core,
that allow to plug different configuration mechanisms. That's exactly
what I'm working on, and hopefully we'll have something like that in 

It seems ProjectHelper plugin has been accepted, and that already
allows you to plug a helper that does whatever it wants with the
attribute values - including what you want. The ProjectComponentHelper
would allow finer control, and we can add hooks for attribute setting.




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

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

View raw message