On Jul 6, 2009, at 8:36 AM, Adam Murdoch wrote:
Hi,
I'd like to tidy-up the Ant integration in preparation for the 0.7
release. I have a few open issues, which I'd like some feedback on.
Here's what you can do with Ant so far:
- 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.
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.
Internally I think it would be good to have this separated into a
plugin. For convenience reasons we might apply this plugin by default.
- 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
This might be related to http://jira.codehaus.org/browse/GRADLE-211
If 211 would be implememted, importAntBuild could be a method of the
Ant convention class and one could use the notation above.
I'm not sure what to do for 0.7. We might add the importAntBuild to
the ant namespace and make it available by default. Later we can
refactor it into a plugin. But I'm not really sure.
'
- 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 reason why we did this (in contrast to the otherwise
DELEGATE_FIRST configuration default) is that so far you would not
want to configure anything. This has changed now, so I think we should
switch to DELEGATE_FIRST.
The problem with this is that then you can't do something like:
def someProjectMethod() { ... }
ant {
ant.echo(message: someProjectMethod())
}
I think the above will work even with DELEGATE_FIRST, unless there is
shadowing caused by the Ant stuff.
If there is shadowing, one can always do: ant.echo(message:
owner.someProjectMethod()). Not very nice, but it is only needed in
case of shadowing.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
