--- Wascally Wabbit <[EMAIL PROTECTED]>
wrote:
> 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.
Obviously we don't want to end up with a net loss of
extensibility. We (or at least, I) am hoping simply
for a better structure to the PH stuff. :) I'm glad
to see you use the term "port", however. Even if
AntXtras is "small", it _is_ used from what I can tell
and we would hope not to irreversibly damage any
dependent project. That is why part of my approach
here has been to attempt to replace or at least point
the direction toward the replacement of functionality.
>
> 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
> PropertyHelper...it
> captures those sets to prevent them from passing
> through to the parent
> project's property set.]]
These first two use-cases are as yet untreated, but
I've been trying to keep them in mind and think about
them. My current feeling is that the props antlib can
provide the notion of a PropertyHelper that delegates
to another PropertyHelper, and a means of
pushing/popping PropertyHelpers into a kind of linked
stack structure. The distinction between this and the
existing PH chain structure is, I think, an important,
though slight, one. From what I have seen of the
AntXtras code, considerable effort is expended
managing the structure of the chain and I think this
is a reflection of the current state of affairs. The
missing piece of the puzzle is, as always, the dilemma
of what to do with threaded processes and scoped
properties. Does AntXtras make any attempt to cope
with this situation? I am still in the process of
reasoning out the implementation of this based on
Peter's experiments with the subject and trying to
determine how much of the supporting code must live in
Ant core vs. how much could be pluggable. I am
thinking mostly the latter ATM.
>
> 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
> PropertyHelper...so providing a set of
> tasks to replace PropertyHelper might be tough if
> not impossible.]]
The PropertyEvaluator interface is our attempt to
accommodate use case 3. I don't see anything in your
above example that can't be accomplished with the new
approach. Again, our goal is to improve the overall
design, not to take away any abilities you currently
have.
-Matt
>
> 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}/deploy.properties">
> ...
> </overlay>
> </foreach>
> </target>
>
>
> 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"/>
> </do>
> ...
> </target>
>
> Hope this helps,
> The Wabbit
>
> Matt Benson wrote:
> >
> > --- Dominique Devienne <[EMAIL PROTECTED]>
> wrote:
> >
> >> On 6/15/07, Matt Benson <[EMAIL PROTECTED]>
> >> 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
> >>
> [snip]
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
