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 Sun, 10 Mar 2002 12:39:17 GMT

On Sun, 10 Mar 2002 11:28, Adam Murdoch wrote:
> > From: Darrell DeBoer []

> I don't think we want a global AntException.  As a general plan, what might
> be useful is a base exception for each major reuse group (aut,
> myrmidon.interfaces, myrmidon.api) and a subclass of these for each API
> group (e.g aut.vfs, myrmidon.interfaces.deployer, etc).
> In the meantime, ProjectException might be good to add, to get thrown when
> something goes wrong building the project model.

Done. I've sent an updated copy of my latest patch (see other email).

> > 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.
> Yeah, possibly.  I'd rather try tackling this using aspects, to keep this
> out of the core, and to avoid a whole bunch of cryptic property ref
> syntaxes.  Aspects give us much greater scope for doing all kinds of stuff,
> on a per object basis (that includes objects nested at any depth), under
> the explicit control of the build-file writer.  Downside will be that the
> syntax for doing stuff will be more verbose.  That is, rather than
> <sometask some-attr="$!{prop}"/>
> you'd have to do something more like this:
> <sometask>
>    <attr:some-attr property="prop" />
> </sometask>
> Of course, the verbose syntax gives us a bucketload more flexibility.  for
> example, the <attr:some-attr> element could have a set of nested condition
> elements e.g. <is-set>, <uptodate>, <class-available>, <os>,
some custom
> condition, etc.

Yep, this is heaps more flexible. Don't quite understand aspects enough to 
understand how they come into play, but sounds good...

> > 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).
> New task, I reckon.  Let's keep the tasks bite-sized, with as few different
> behaviours as possible.

Something to add to the todo - any suggestions for a task name?

> > 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 "$$!{")
> +1 to this.  Isn't DefaultPropertyResolver working this way already?

Yep, but I thought that the comment 
    // TODO: check if this is commented out
might have indicated that this was just NYI. Maybe the easiest implementation 
is to remove the comment ;).

> > 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)?
> All of the above.  There are valid use cases for each of these behaviours,
> so the trick is to come up with a model that lets the build file writer
> decide which behaviour is appropriate for each property usage.  And to come
> up with a syntax that is as terse as possible, but expressive enough.
> We also have to decide how <ant> and <antcall> fit into the model.

Seems like it needs some thought. Something else for the todo.

> > e) Recursive property resolution, like
> >             srcdir="${build.${current-project}.dir}".
> > Not sure how useful this would be, but could always play around with it.
> Looks like the code is ready to go, may as well switch it on.

OK, but I haven't written any tests for it yet ;). I guess there's no reason 
not to include this as the default behaviour, now that the NameValidator 
ensures that the "$" character can't be a part of a property name. (ie - it's 
never going to bite someone who doesn't want it).

Thanks for your comments

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

View raw message