Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
From: "Adam Murdoch" <adammurdoch_ml@yahoo.com>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Subject: RE: [myrmidon] PATCH: PropertyResolver service.
Date: Sun, 10 Mar 2002 11:28:17 +1000
Message-ID: <CLEMKEJLBJDGBHEDNCPHMELFEFAA.adammurdoch_ml@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200203090304.g2934IN05531@mail008.syd.optusnet.com.au>
Importance: Normal


> -----Original Message-----
> From: Darrell DeBoer [mailto:darrell@apache.org]
> Sent: Saturday, 9 March 2002 1:17 PM
> To: Ant Developers List
> Subject: Re: [myrmidon] PATCH: PropertyResolver service.
>
>
> 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...;)
>

Yeah, it's a bit too general.  Good enough for now, though.

> >
> > * 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?

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.


> (It looks
> like ProjectBuilder just uses base java.lang.Exception, but is
> this what we
> really want?)
>

Nope.

> * 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.
>

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.

Or a bunch of nested resolver elements like <base-name>, <regexp-replace>,
<now>, <path-convert>, etc.

Not necessarily the kind of stuff we might include in the core, but
certainly it could be made available with a quick <import> of the
appropriate antlib.


> 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.

> 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?

> 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.


> 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.


Adam


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>