jython does support named parameters, one
can do some bizarre stuff:
<script language="jython">
from java.io import File
def twrapper(taskname, **args):
t = project.createTask(taskname)
for a in args.keys():
exec("t.%s = %s" % (a, args[a]))
t.execute()
twrapper('echo', message="'hello world'")
twrapper('delete', quiet="1", dir="File('todir')")
twrapper('mkdir', dir='File("todir")')
twrapper('copy', file='File("fromfile")', todir='File("todir")')
</script>
output:
hello world
Deleting directory /home/preilly/proj/learning/outofdate/todir
Created dir: /home/preilly/proj/learning/outofdate/todir
Copying 1 file to /home/preilly/proj/learning/outofdate/todir
Peter.
On Friday 13 June 2003 06:23, Conor MacNeill wrote:
> 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/Atti
>c/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/or
>g/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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
