ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: Embedded dynamic ANT tasks.
Date Wed, 11 Jun 2003 12:15:54 GMT
On Wed, 11 Jun 2003 09:24 pm, Jose Alberto Fernandez wrote:
> Connor,
> Can you expand on why DynamicConfigurator wasn't an option for
> your ScriptBaseDef class? 

Actually I think it could (should) be used. I thought originally that since 
createElement was called at config time, I would need to know the actual  
class to be returned then and there. Since I was getting the script 
definition at execute time, the info would not be available at config-time. 
That reasoning is, however, bogus. The tasktype has been set before config 
takes place so the taskdefinition and type lookup could occur in the 
createElement method. It would simply be a matter or moving the code around a 
little and storing the elementInstances map in the ScriptDefBase class. 
Actually I think I should make this change as it is clearer than using the 
TaskContainer interface to prevent configuration.

> I would love to be able to write scripting
> tasks as close as the java as possible, that way one could use
> scripting for prototyping and eventualy move it into classes
> once the task is defined enough. (I am assuming BSH here).

This is possible for javascript and, I guess, BSH. Is it possible for all BSF 
supported scripting languages - I don't know? You'll remember the code in 
Mutant worked this way. Actually the current <scriptdef> implementation does 
not use the setXXX style due in part to the feedback to that proposal. Check 
out the full thread:

<scriptdef> could work that way, perhaps as an option but I think perhaps 
Dawid's approach is more worthwhile for task prototyping since, as Peter 
( it could be 
used to implement other components such as selectors. Pretty cool. 

So perhaps Dawid's DynamicBSH thing for prototyping and <scriptdef> for simple 
scripts where you don't want all the setXXX machinery, which can be tedious.

> Do you provide a "src" attribute on <scriptdef/> so that the code
> can be on a file? That could be good for large code.

Good idea. I'll try to get around to it, and also a classpath for the 
classname approach to nested element creation (or just scrap that concept 
completely and just rely on type names).


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

View raw message