Using convention mappings with Copy-derived tasks

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Using convention mappings with Copy-derived tasks

pledbrook
Hi,

I'm encountering a couple of occasions where I want to map the
properties of a plugin extension to the properties of a Zip task. This
works fine except for certain properties such as `excludes` and
`fileMode`. These are really properties on the underlying CopySpec and
that seems to cause the convention mapping issues.

I raised this as a question on the forums[1] but essentially

    task.conventionMapping.map("excludes") {
        project.extensions.lazybones.excludes
    }

doesn't work if `task` is a Copy-derived task. Should this be
possible? If so, shall I raise a JIRA issue for it?

Thanks,

Peter

[1]: http://forums.gradle.org/gradle/topics/how_do_i_map_a_plugins_extension_property_to_a_copy_tasks_excludes

--
Peter Ledbrook
t: @pledbrook
w: http://www.cacoethes.co.uk/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using convention mappings with Copy-derived tasks

Luke Daley-2
Have you tried convention mapping to the root spec? 


This is internal API, but you’re already in this hole with convention mappings.

On 22 August 2014 at 2:05:45 am, Peter Ledbrook ([hidden email]) wrote:

Hi,

I'm encountering a couple of occasions where I want to map the
properties of a plugin extension to the properties of a Zip task. This
works fine except for certain properties such as `excludes` and
`fileMode`. These are really properties on the underlying CopySpec and
that seems to cause the convention mapping issues.

I raised this as a question on the forums[1] but essentially

task.conventionMapping.map("excludes") {
project.extensions.lazybones.excludes
}

doesn't work if `task` is a Copy-derived task. Should this be
possible? If so, shall I raise a JIRA issue for it?

Thanks,

Peter

[1]: http://forums.gradle.org/gradle/topics/how_do_i_map_a_plugins_extension_property_to_a_copy_tasks_excludes

--
Peter Ledbrook
t: @pledbrook
w: http://www.cacoethes.co.uk/

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

http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using convention mappings with Copy-derived tasks

pledbrook
> Have you tried convention mapping to the root spec?
>
> https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/org/gradle/api/tasks/AbstractCopyTask.java#L96-96
>
> This is internal API, but you’re already in this hole with convention
> mappings.

Does that mean convention mappings aren't the correct approach? I
haven't seen an alternative mechanism, although directly assigning the
extension property to the task property seems to be working for now.
I'm just not sure whether it will continue to work.

Thanks,

Peter

--
Peter Ledbrook
t: @pledbrook
w: http://www.cacoethes.co.uk/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using convention mappings with Copy-derived tasks

Luke Daley-2


On 22 August 2014 at 4:36:06 pm, Peter Ledbrook ([hidden email]) wrote:

> Have you tried convention mapping to the root spec? 
> 
> https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/org/gradle/api/tasks/AbstractCopyTask.java#L96-96 
> 
> This is internal API, but you’re already in this hole with convention 
> mappings. 

Does that mean convention mappings aren't the correct approach? 

This is one of the problems with convention mapping yes.

I 
haven't seen an alternative mechanism, although directly assigning the 
extension property to the task property seems to be working for now. 
I'm just not sure whether it will continue to work. 

The problem you’ll have here is that you are now sharing this map around. If it’s changed in one place it’s going to be changed everywhere.




Loading...