ant integration issues

[Adam Murdoch-2]

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.

- 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'

- 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?


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

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: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[hdockter]

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

[Adam Murdoch-2]

Hans Dockter wrote:

>
> 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.

I think I might get rid of the Ant plugin for this release. The actual
code for the integration is tiny, and it does not drag in any
dependencies that were not there already. We can split this out into an
auto-applied plugin (or whatever) when we modularise Gradle.

>
>>
>> - 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.
>

I think I will move importAntBuild() from the Ant plugin convention to
our AntBuilder subclass for this release.

>> '
>>
>> - 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.
>

It does. Cool.


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email