So of course, right after sending this, I found a workaround for my particular use case - switching from DELEGATE_ONLY to DELEGATE_FIRST got my tests passing. But I'm still curious to know if there's a way to do this in general. =)
A. On Fri, Sep 23, 2016 at 9:28 AM, Andrew Bayer <[email protected]> wrote: > So I've got a DSL that has a section that looks like > https://gist.github.com/abayer/a0bfbb531457e79aabc8d6c25d992e62, which > ends up translating (via https://github.com/jenkinsci/pipeline-model- > definition-plugin/blob/master/src/main/resources/org/ > jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy > and then https://github.com/jenkinsci/pipeline-model- > definition-plugin/blob/master/src/main/resources/org/ > jenkinsci/plugins/pipeline/modeldefinition/PropertiesToMapTranslator. > groovy) into a Map, and later on I actually do things with the contents > of that Map in a different context entirely. Fun, right? > > So the literal syntax works fine, but non-literals get evaluated when I > call the closure to translate it into a Map. I don't want that - it causes > problems due to not being called in the context that actually has the > "getFruit()" and "getCandy()" methods (and due to the Jenkins Pipeline > Groovy CPS magic for continuation passing style and script security that > make things even weirder). I'd really, really love to be able to lazily > evaluate the property values here while still having dynamic properties, > since I don't know what the names of all the environment variables people > may need will be. > > Anyone have any suggestions or ideas? I've looked at the @Lazy field > annotation, which would be perfect if I could use it with dynamic > properties, but I can't see a way to actually do that... > > Thanks! > > A. >
