ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <>
Subject Re: cvs commit: jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/components/property/test
Date Thu, 21 Mar 2002 02:42:00 GMT
On Thu, 21 Mar 2002 11:34, Adam Murdoch wrote:
> > -----Original Message-----
> > From: []

> public String getProperty( String name )
> {
>     Object value = m_context.getProperty( name );
>     if ( value != null )
>     {
>         return getConverter().convert(value, String.class, m_context);
>     }
>     else {
>         return null;
>     }
> }
> Not so useful for an all-ant1 project, but definitely handy for bridging
> between ant1 and and ant2 tasks.  For example, this could be a simple
> solution for converting ant2 paths -> ant1 paths:
> <project version="2.0">
>   <my-dodgy-home-made-ant2-path-implementation id="classpath" ...>
>   <ant1.javac classpath="${classpath}" ... >
> </project>
> Probably also less potential for confusion if we convert object properties
> to string rather than ignoring them, so that non-string ant2 properties
> don't mysteriously go missing.

Yep. I've been focussing on pure-Ant1 buildfiles, and only needed to add in 
the property hooks so that I could implement <target if="?" unless="?"> 
functionality. (which is implemented using the Myrmidon "if" Task, and needs 
access to the Ant1 properties). I haven't too much effort into getting Ant2 
properties into the Ant1 compatibility layer - so far I've just been using 
existing Ant1 projects as tests, but I spose I'd better start writing some 
proper tests.

I reckon the use of converters would be the most flexible - let's go with 

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

> Some other random comments about Ant1CompatProject:
> * First up, this really is very cool.  Heaps simpler than I imagined a
> compat layer looking (though I guess it's not done yet).

Thanks. I too am surprised with how quickly it is falling into place. 
Basically, keeping the Task code the same, but replacing ProjectHelper, 
RuntimeConfigurable and friends with simple configuration at run-time 
simplifies things greatly.

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. I need to delve deeper into the 
Ant1 codebase.

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.

> * You should push some of the refactoring down into Project in the ant 1
> tree, to make sub-classing easier.  In particular, it seems unfortunate to
> have to override things like setProperty(), setNewProperty(),
> setUserProperty(), and all that.  Much better if you could simply override
> a doSetProperty(), a doGetProperty() and a doGetPropertyNames() (or
> whatever, you get the idea).  This would be healthy for the ant 1 tree, and
> would help isolate Ant1CompatProject from changes to Project.  Though I
> guess this stuff is still in prototype mode.

I guess these refactorings would be helpful, but I'm still pretty new around 
here, and Project is *reasonably* fundamental to the whole of Ant, no? ;) I'm 
not too keen on making changes to the Ant1 tree with log messages like:
"* Added protected accessors to underlying properties map, so that Myrmidon 
Ant1 compatibility layer can more easily override them."
(Especially if those changes are subsequently not required.)

But you're right, maybe I need to keep a copy of Project in the Myrmidon 
tree, and make changes to that. Then when it's stabilised a little and I feel 
confident with them, I can see about pushing those refactorings up into the 
Ant1 tree.

> * You should re-contextualise the project at the start of each task's
> execute() method (that is, reset the m_context field).  This is because the
> context for a task is in no way guaranteed to be the same object for every
> task in a project (though it just happens to be at the moment).  Nor is
> there any guarantee that a context will remain usable once Task.execute()
> has returned.

ok, will do.

> Adam

Thanks for the pointers.

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

View raw message