« Return to Thread: ant integration issues

Re: ant integration issues

by hdockter :: Rate this Message:

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

« Return to Thread: ant integration issues