ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <>
Subject Re: [myrmidon] PATCH: PropertyResolver service.
Date Sat, 09 Mar 2002 03:17:18 GMT

On Sat, 9 Mar 2002 12:02, Adam Murdoch wrote:
> Hi,
> Applied - thanks.

Cool, thanks.

> * Use Avalon's Context instead of PropertySet interface.  Doesn't really
> seem worth adding yet another 'find this object by key' interface, at least
> for the time being.  Context is close enough.  We need to address the fat
> TaskContext vs a map of objects issue in a few other places as well, so
> let's hold off on PropertySet.  Unless you see PropertySet evolving into
> something more than a single lookup method?

Fair enough. I was trying to avoid having ContextExceptions being thrown and 
ignored/rethrown when the property wasn't present. And I didn't really like 
adding the rather mysterious:
    public Object get( Object o );
to DefaultTaskContext...;)

> * ClassicPropertyResolver returns ${propname} for undefined properties,
> rather than an empty string.  This is how Ant 1 behaves.

Oops, thanks.

I have a few questions moving forward:
* I'm starting to work on the Project and Target name validation, basically 
with a NameValidator component. 
    void validate( String name ) throws ????Exception
I guess we don't want a new Exception type for every component (or at least 
we don't have so far), but TaskException doesn't really fit. Should we add a 
ProjectException/AntException or something similar for these cases? (It looks 
like ProjectBuilder just uses base java.lang.Exception, but is this what we 
really want?)

* Continuing on with the PropertyResolution stuff, there have been some 
interesting ideas on this list in the past day or 2. What are thoughts on 
some things like:

a) Syntax and behaviour for optional properties. Default behaviour is to 
throw an Exception for undefined properties, but we could possibly provide a 
mechanism whereby $!{propertyName} could return null (or, say, 
NULL_PROPERTY), and the configurer would simply ignore this attribute.

b) Now that properties are mutable by default, there are many cases where 
we'll want behaviour similar to Ant1, whereby the value is only set if the 
property is undefined. I guess this can be done with a condition on the 
property task, but something simple and clean would be good ( a new task, or 
option on Property task).

c) Different escaping behaviour. IMHO leaving a lone "$" sign would cause 
less user confusion than silently removing it. The only time a "$$" would be 
needed would be to escape a property definition (eg "$${" or "$$!{")

d) Properties scoped at the Workspace, Project and Target level. (I stole 
this from "requested-features.html", but I'm sure there is a lot more to 
it!). How would these be differentiated? If propX is defined at the project 
level, and then again in a target, is the project property hidden, or 
modified (or is this disallowed)?

e) Recursive property resolution, like
Not sure how useful this would be, but could always play around with it.


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

View raw message