ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: cvs commit: jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/components/property/test
Date Thu, 21 Mar 2002 03:41:39 GMT

> -----Original Message-----
> From: Darrell DeBoer []

> >
> > Using the converter, rather than Object.toString() is probably a better
> > option for actually doing the object -> string conversion,
> since many ant2
> > data-types won't be able to toString() themselves without a
> TaskContext to
> > help.
> >
> > If we went with using the converter, we'd want to change the property
> > resolvers to use the converter as well.  We'd also have to add a generic
> > ObjectToStringConverter.  Minor things.
> Yep, this would be very cool. Does this mean we might be able to
> do away with
> the <task XXX-ref="?"> syntax? (or at least reduce the need for it) Seems
> like treating references just like properties would be nice and simple.

That works already (well, it was working).  You can do stuff like:

<path id="somepath" ... />
<some-task classpath="${somepath}" />

And the path object gets passed to the task by reference.  So I guess we
*could* get rid of the -ref form for references.  Hmm... maybe we should.

However, what I was referring to was something more like this, where an
attribute value has to get converted to a String:

<path id="somepath" ... />
<some-task classpath="${some-path};build/lib;${some-other-path}"/>

In this case, the property resolver has to convert the Path object to
String, and so probably should be using the converter to do so.

> I want to do a bit more work on the configuration stage, to more closely
> mirror the subtleties of Ant1. Things like processing elements before
> attributes, although I think this is dependent on whether the
> task is in the
> implicit target, or within a defined target.

Or nested in a TaskContainer, or an implicit type, or whether the typedef
for the type is in the implicit target, or ...  you get the idea.

> I'm not yet sure how tasks like <script> and task containers are going to
> work. (I doubt they are working now, and I've never really played
> with them
> in Ant1) Maybe we can just use the Myrmidon replacements? It's
> still early
> days, really.

I guess we have to draw the line somewhere - we just aren't going to get to
an absolute 100% compatibility.  Task containers might not be too painful,
using an adaptor for the nested tasks (or whatever).  Script, on the other
hand, is going to be very, very difficult to get 100% right, because it
exposes way too much of the internals that just aren't there any more.  We
should probably just leave <script> as it is, and whatever works, works.
Some stuff will.

I guess we just let gump decide what we have to fix.


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

View raw message