BeanDynamicObject seems to block properties set via a Category


(Justin Ryan) #1

For the gradle-rpm-plugin, we use @Category(ReadableCopySpec) to add some methods and properties that are specific our version of a CopySpec, e.g. rpm file type or if we should create a directory entry. In 1.7, it looks like the methods are working just fine from the Category but the property setters no longer work. Did something change with the behavior with BeanDynamicObject to make it no longer use GroovyCategorySupport?


(Peter Niederwieser) #2

I can’t answer the specific question, but I don’t recommend to use Groovy runtime metaprogramming when extending Gradle. Gradle pulls a lot of its own metaprogramming tricks, and as you probably know, these things don’t compose well. The general idea (which might not help in this case) is that only Gradle’s own metaprogramming facilities (e.g. extensions) should be used.


(Justin Ryan) #3

In the CopySpec, the creation of the object is done internal to CopySpecImpl, and then a closure is called. There is no opportunity, e.g. callback, for me to add method/properties to the object before the closure that uses the child CopySpec is evaluated. I don’t believe Extensions would help me. I also don’t want to pollute CopySpecs outside of the scope of our tasks and our extension.


(Peter Niederwieser) #4

I see. There was a change in 1.7 in that copy specs are now enhanced objects. Maybe that’s why Groovy categories stopped working. If you need a reliable way to enhance the CopySpec API for your task, I recommend to kick off a discussion on the dev list, where it will likely get more dev attention (including Adam’s).