ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Cato <>
Subject Re: PropertyHelper thoughts
Date Sun, 01 Jul 2007 06:17:24 GMT
Hello all,

Sorry I've not been particularly linked into the Ant developers mailing 
list recently...however, this is a discussion that might result in 
significant pain for me if I don't chime in with my 2cents.

Rather than try to speak to specific points in this thread (some of 
which I'm sure I've missed completely), I'll just describe how AntXtras 
hacks...sorry "leverages"...PropertyHelper. While AntXtras is a small 
project, hopefully the redone PropertyHelper+friends won't make any of 
the AntXtras features impossible to port.

Three Primary Uses for PropertyHelper (AntXtras-Universe):

1) To overlay a set of properties for a specific scope; particular the 
scope of a task container's execution. Such containers (or tasksets as I 
call them) are not related to macrodefs although the overlay might be 
done to setup fixture for a call to a macrodef. The ability to 
temporarily overlay a set of properties is useful to me as I use AntX as 
a part of a test management system where Ant acts as harness builder and 
launchpad-- the same thing is done N times w/ only the overlaid 
properties changed to test various scenarios. Note the overlaid 
properties will override any existing properties for that container's 
scope. Also overlay is often simpler than setting up subant or antcall 
for simple tasks. Overlays also used to create nested logger contexts 
within log4Ant.

2) To isolate and control a set of property and reference modifications 
to a specific scope. Again this is within the scope of any task 
container and is not limited to macrodefs. This compliments the overlay 
function in that it captures undesired side-effects from executing a 
reused set of tasks (macrodef, AntX various flow-control tasksets, etc.) 
Additionally, the build script can pick-n-choose which modifications it 
wants to let pass through to the project's scope. [[The BIG point here 
is that isolate relies on the *SET* functionality of 
captures those sets to prevent them from passing through to the parent 
project's property set.]]

3) To implement an AntXtras feature called "value URIs" where you can 
use the standard Ant ${...} property form to inline more complex 
function calls for property values . For instance, ${$longtime:} 
includes a time string of the Ant JVM's current system time as the value 
while ${$property:label|$uppercase:} lets you upper case the contents of 
the 'label' property without creating another temporary property. [[The 
point here is that recursive property expansion and/or scoped properties 
aren't the only games in town for providing a set of 
tasks to replace PropertyHelper might be tough if not impossible.]]

Silly Examples (creativity a bit shot):

1. Overlays
<target name="deployments" depends="...">
   <assert isref="deployments.d"/>
   <foreach i="deployment.d" dirs="${deployments.d}" mode="local">
     <overlay file="${deployment.d}/">

3. Value URIs
<target name="workspace" depends="...">
   <echo message="Started: ${$time:}" level="info"/>
   <do unless="os.disabled">
     <property file="${conf.d}/build-${$os:|$lowercase:}.properties"/>

Hope this helps,
The Wabbit

Matt Benson wrote:
> --- Dominique Devienne <> wrote:
>> On 6/15/07, Matt Benson <>
>> wrote:
>> > I am actively working on this as we speak,
>> actually,
>> > and I'm pleased so far with my results.
>> FTR Matt, I still haven't read anything to convince
>> me that write
>> access via <property> is desirable, needed, and
>> good. I'm not trying
>> to put a damper on your efforts, but so far the use
>> cases I've seen
>> for "write" are better handled by custom tasks.
> Okay, first to be more clear:  I determined that the
> natural extension points for properties handling would
> be, reading them, expanding them from a string (the
> use case that kicked off this discussion), and setting
> them.  I did and do recognize that changing how
> properties are set was weird, and as such have still
> not even written the interface for how that would
> happen.  Even if the final group consensus is to allow
> for them, I am putting them last, and who knows?  I
> might not even be the one to implement them in the
> event we do go forth with them.  :)
>> What about the <*ant> tasks? These "things" which
>> are not string
>> properties, how do they percolate to sub-Projects?
>> We have clear
>> semantic for properties and references passing, so
>> it would be much
>> clearer and "The Ant Way"(tm) to have them as
>> references, manipulated
>> using custom tasks, and passed using reference
>> semantic, and which
>> unlike properties are not fully compartmented
>> between Projects, which
>> the parent and child project share the same
>> referenced-object.
> Here you've simplified "pluggable property setting" to
> "supporting non-String properties" and I suppose
> that's fair enough from a buildfile-only standpoint. But the current 
> design of PropertyHelper allows for a
> given property to be set as an arbitrary object via
> Ant's API.  I think, even if we don't recognize that
> we should allow a hook for setting properties, that
> this is harmless enough, despite your well-founded
> arguments regarding references.  That said, it's no
> concern of mine if we reduce properties to Strings--it
> would simplify some things, certainly--but the user
> community might feel otherwise.  Then again, (1) if
> we're already giving them breaking changes we can
> certainly go whole-hog with those if we so choose, and
> (2) I sent Wascally Wabbit from AntXtras (who seem to
> be the greatest consumer of PropertyHelpers from the
> list Peter sent out) a personal message inviting him
> to this conversation and we still haven't seen him. I'll follow up with 
> a similar message to the other
> admin on the project in case he's on vacation or
> something.  Meanwhile I'll try restricting properties
> to strings and see if we break anything internal.
>> Would installed PH instanced percolate to
>> sub-Project automatically?
> I'm not sure.  I think we need more discussion of
> this:
>> Because if they do, Peter's argument that the
>> explicit declaration of
>> the PH ensures BC falls flat if one uses "external"
>> reusable build
>> files which would happen to use the same syntax as
>> the PH prefix
>> installed in another build file. That would be bad
>> encapsulation.
>> So the more I think about this, the more I feel it's
>> wrong at several level.
> I don't necessarily agree that the PropertyHelper
> should be externally configurable (via, I assume,
> magic properties).  I think we'll be in better shape,
> personally, to simply provide a reasonable set of
> tasks to replace PropertyHelpers and add handling
> delegates to the currently installed PH, all from
> within the buildfile.  It's a similar argument to why
> externally declared namespace prefixes are wrong, and
> so I am confident you and I will (for once) be in
> agreement on this point.
>> Let's stick with read access. As toString:
>> demonstrates already,
>> what's to the right of the PH scheme doesn't have to
>> reference a
>> property name, so it's flexible enough. --DD
> Final thought wrt not allowing for setter delegates: Because we plan to 
> continue to allow a user to install
> an arbitrary subclass of PropertyHelper we would have
> to make setXXX final operations to stop a determined
> user from doing I-can't-foresee-what kind of things
> with property setting.  Are we prepared to do this?
> -Matt

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

View raw message