Adam, On Mon, 2009-07-06 at 16:36 +1000, Adam Murdoch wrote: [ . . . ] > - Access Ant tasks and types from you build script using the 'ant' > AntBuilder property (ie what you could do in Gradle 0.6) > > - Access Ant properties and references as properties of the AntBuilder, > eg ant.someProperty = 'some value' > > - Import an Ant build.xml into the project, where each Ant target is > accessable as a Gradle task.
I had made a start on a Gradle Ant Task to allow calling of Gradle from an Ant build.xml. I really should have finished it by now but stuff got in the way. I think having the ability to interwork Gradle and Ant in both directions will be important for migrating people from Ant to Gradle since good integration allows for migrating parts of an overall build and hence an evolutionary rather than revolutionary change -- and revolutionary change happens rarely. > See http://gradle.org/latest/docs/userguide/ant.html for some examples. > > Some issues: > > - You don't have to do anything to get the Ant task, type and property > integration in your build script, but to be able to import an Ant build, > you need to use the 'ant' plugin. This seems a bit inconsistent to me. > It feels like you should either get all of the Ant integration by > default or none of it, rather than just some bits of it. Perhaps we > should get rid of the 'ant' plugin? The other option would be to remove > the 'ant' property from the core Project interface, and have the 'ant' > plugin add it in, so that you can't use any Ant stuff without using the > 'ant' plugin. Consistency is good. I guess the issue is whether access to Ant tasks is deemed core Gradle or add-in Gradle. In the former case everything should always be available in the latter case nothing should be available by default only after including the ant plugin. > - Currently you use importAntBuild 'some-build.xml' to import an Ant > build. Should we move this to the 'ant' namespace? ie, change this: > > importAntBuild 'build.xml' > > to: > > ant.importBuild 'build.xml' Isn't this question answered by the previous one. The former is best when integration is automatic, the letter is best when everything depends on the including of the plugin. > - The ant(closure) method sets the resolve method of the closure to > OWNER_FIRST. This means you can't do something like: > > ant { > someAntProp = 'someValue' > } > > as this sets the property on the Project, instead. Should we change this > to DELEGATE_FIRST? The problem with this is that then you can't do > something like: > > def someProjectMethod() { ... } > > ant { > ant.echo(message: someProjectMethod()) > } > > We could probably do some custom resolution, so that setProperty and > getProperty() resolve using the delegate first, and invokeMethod() > resolves using the owner first. > > Any thoughts? I'll have to pass on this last point. -- Russel. ============================================================================= Dr Russel Winder Partner xmpp: [email protected] Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 voip: sip:[email protected] London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder
signature.asc
Description: This is a digitally signed message part
