Hi,
On Sun, 10 Mar 2002 11:28, Adam Murdoch wrote:
> > From: Darrell DeBoer [mailto:[EMAIL PROTECTED]
> 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
ciao
Daz
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
