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 ProjectComponentHelper. Thanks. Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 I > 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 ant1.5. 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. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
