Return-Path: Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 92396 invoked by uid 500); 13 Jun 2003 09:55:17 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 92377 invoked from network); 13 Jun 2003 09:55:16 -0000 Received: from k101-36.bas1.dbn.dublin.eircom.net (HELO corvil.com.) (159.134.101.36) by daedalus.apache.org with SMTP; 13 Jun 2003 09:55:16 -0000 Received: from preilly.local.corvil.com (preilly.local.corvil.com [172.18.1.173]) by corvil.com. (8.12.5/8.12.5) with ESMTP id h5D9tOtn095977 for ; Fri, 13 Jun 2003 10:55:25 +0100 (IST) (envelope-from peter.reilly@corvil.com) Content-Type: text/plain; charset="iso-8859-1" From: peter reilly Organization: corvil To: Ant Developers List Subject: Re: Ant scripting from Jython. Date: Fri, 13 Jun 2003 10:59:29 +0100 User-Agent: KMail/1.4.3 References: <41D11C2C-9D4C-11D7-9EDE-000393DB198C@x180.net> <200306131523.19303.conor@cortexebusiness.com.au> In-Reply-To: <200306131523.19303.conor@cortexebusiness.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200306131059.29792.peter.reilly@corvil.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N jython does support named parameters, one can do some bizarre stuff: 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-use= r > that are somewhat related to this topic. > > http://marc.theaimsgroup.com/?l=3Dant-dev&m=3D105516662409107&w=3D2 > > and > > http://marc.theaimsgroup.com/?l=3Dant-user&m=3D105491111510585&w=3D2 > > Instead of the "script driving Ant tasks" approach, 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 wh= ole > 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 > > =09 todir=3D"C:\java\jython_ant\temp"/> > > In fact because the attributes are named, the XML is easier to understa= nd > as it does not rely on implicit position-dependent parameters. IT's mor= e > 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 introspecti= on > 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 mo= stly > everything else takes sensible defaults. In the copy example, think abo= ut > what the wrapper would look like that exposes all the capabilities of > > (http://ant.apache.org/manual/CoreTasks/copy.html). I think it could be > quite ugly unless your scripting language also supports named attribute= s - > 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 J= ava > program. It was effectively a build compiler (part of Mutant's botostra= p > process). > > Here's the XSL > http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/proposal/mutant/build/= Atti >c/bootstrap.xsl?rev=3D1.3&content-type=3Dtext/plain > > You can see the result here. > http://cvs.apache.org/viewcvs.cgi/ant/proposal/mutant/src/java/bootstra= p/or >g/apache/ant/builder/Attic/MutantBuilder.java?rev=3D1.7&content-type=3Dt= ext/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 met= hod > calls. I had to limit myself to a very narrow subset of tasks and their > usage patterns. > > Conor > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org > For additional commands, e-mail: dev-help@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org