Hi Duncan,

You all might like to look at two recent threads in ant-dev and ant-user that 
are somewhat related to this topic.

http://marc.theaimsgroup.com/?l=ant-dev&m=105516662409107&w=2

and

http://marc.theaimsgroup.com/?l=ant-user&m=105491111510585&w=2

Instead of the "script driving Ant tasks" approach, <scriptdef> is more like a 
script within a task. As such, the scripts would potentially be more focussed 
on the things that need to be scripty rather than doing the whole build in 
the script. After all, IMHO,

copyWrapper("C:\\java\\jython_ant\\src\HelloJython.java",
"C:\\java\\jython_ant\\temp", project)

doesn't end up any "better" than

<copy file="C:\java\jython_ant\src\HelloJython.java" 
          todir="C:\java\jython_ant\temp"/>

In fact because the attributes are named, the XML is easier to understand as 
it does not rely on implicit position-dependent parameters. IT's more redable 
which is probably counter-intuitive.

In terms of Jonathan's original need for wrappers, there is some possibility 
that they could be auto-generated using the Ant introspection facilities. One 
problem is that most Ant tasks support a multitude of attributes. As I said 
above, XML is quite nice there as it allows attributes to be named. You only 
provide the attributes you want and mostly everything else takes sensible 
defaults. In the copy example, think about what the wrapper would look like 
that exposes all the capabilities of <copy> 
(http://ant.apache.org/manual/CoreTasks/copy.html). I think it could be quite 
ugly unless your scripting language also supports named attributes - I have 
limited experience with Jython, so I can't say.

BTW, I once experimented with converting build files to scripts (code 
actually). I  wrote an XSL template to turn a simple Ant build into a Java 
program. It was effectively a build compiler (part of Mutant's botostrap 
process).

Here's the XSL
http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/proposal/mutant/build/Attic/bootstrap.xsl?rev=1.3&content-type=text/plain

You can see the result here.
http://cvs.apache.org/viewcvs.cgi/ant/proposal/mutant/src/java/bootstrap/org/apache/ant/builder/Attic/MutantBuilder.java?rev=1.7&content-type=text/vnd.viewcvs-markup

Not that useful but a bit more grist for this mill. It certainly showed me 
that it is hard to cram the expressiveness of the XML approach into method 
calls. I had to limit myself to a very narrow subset of tasks and their usage 
patterns.

Conor



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to