groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Bayer <>
Subject Re: Lazy evaluation of properties in a closure?
Date Fri, 23 Sep 2016 17:07:12 GMT
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. =)


On Fri, Sep 23, 2016 at 9:28 AM, Andrew Bayer <>

> So I've got a DSL that has a section that looks like
>, which
> ends up translating (via
> definition-plugin/blob/master/src/main/resources/org/
> jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy
> and then
> 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.

View raw message