Есть некоторый грувишный скрипт с jenkins dsl: job('cron') { triggers

{
cron('#')
}
}
тут вызываются функциеподобные job и triggers, в которые передаются замыкания с какими-то действиями, и в итоге создаётся объект в дженкинсе и все счастливы

выношу вызов крона в отдельную функцию,
def mycron(x) {
cron(x)
}
, вызываю mycron('#') внутри triggers, дженкинс грязно ругается:
No signature of method: script.cron() is applicable for argument types: (java.lang.String) values: [#]
окей, логично, у самого объекта скомпилированного скрипта крона действительно нет

вертаю всё назад, дёргаю другую сигнатуру навроде cron(1, '#'):
No signature of method: javaposse.jobdsl.dsl.helpers.triggers.TriggerContext.cron() is applicable for argument types: (java.lang.Integer, java.lang.String) values: [1, #]
отлично, крон это метод TriggerContext, возвращаю вызов своего mycron(), в нём дёргаю javaposse.jobdsl.dsl.helpers.triggers.TriggerContext.cron(x):
No signature of method: static javaposse.jobdsl.dsl.helpers.triggers.TriggerContext.cron() is applicable...
тоже логично, крон не статическая функция, ему нужен объект... вот только откуда мне этот объект взять?

курил манул, пытался играться с this, owner, {owner}(), делегатами и стратегиями резолва оных, но остался у разбитого корыта
собственно вопрос: можно ли как-то так хитро написать mycron(), чтобы можно было его смело использовать внутри замыкания в triggers как обычный cron()? т.е. есть конечно вариант такой травы:
def mycron(obj, x) {
obj().cron(x)
}
mycron({owner}, '#')
, но какой-то он немножко кривой, хочется просто mycron('#')

вариант "нельзя" принимается, но тогда хотелось бы какое-то минимальное пояснение, как эта магия вообще работает, и почему в изначальном варианте крон резолвится куда надо, хотя оба замыкания вроде как инстанцируются в моём скрипте

чет вопрос не по теме чата (( лично я стараюсь скрипты jenkins dsl делать максимально простыми, чтоб поменьше иметь дел с "магией", здесь лучше спросите https://t.me/devops_ru

Может быть, @bsideup поможет в этом деле?

понятия не имею че там в груви и темболее в его dsl`ах, но возможно вам помогут рассуждения со стороны такое чувство что job('cron') - создает экземпляр какого-то конкретного класса из библиотеки dsl`я, в котором есть поле или метод triggers которая содержит конкретный объект конкретного класса, в котором есть поле/метод cron который в конечном счете вызывается. эх жалко что в груви нет имплиситов чтобы неявно передавать контекст (хотя вероятно даже в скале бы вам в данной ситуации это не особо бы помогло) но вы можете сделать по аналогии с текущим решением - на наследовании вам нужно сделать некий метод myJob, который создает экземпляр уже ВАШЕГО класса Job, в котором есть поле triggers или myTriggers, в котором лежит объект вашего второго класса, который наследует исходный TriggerContext, в котором вы добавляете есть поле/метод myCron в котором уже доступен обычный cron тк они в рамках одного класса (надеюсь там не private cron) собственно, вообще говоря в таком случае возможно вам myCron и не нужен, а нужно переопределить cron в наследнике, а если вы хотите вызывать в конце него изначальный крон - сделать super.cron(..)