Hi,
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
srcdir="${build.${current-project}.dir}".
Not sure how useful this would be, but could always play around with it.
ciao
Daz
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
