Увы, JIRA как платформа по поддержке workflow не идеально поддерживает связь workflow и изменения значений полей.
Применяя ваш подход к моему примеру с назначением на группу:
в первом случае мы либо отказываемся от использования системного поля Assignee, что нехорошо, потому что под него много чего в системе уже написано полезного; либо будем вынуждены обновлять/откатывать значение assignee при ошибке валидации уже после обновления в отдельной транзакции, что тоже нехорошо, т.к. можем поломать консистентность данных ишью между транзакциями. Точки входа, где мы могли бы провалидировать значения всех полей внутри одной транзакции обновления, у нас нет.
во втором случае изменение поля Assignee не вызывает перехода по workflow, а это значит ни один workflow валидатор или постфункция вызвана не будут
Я не отрицаю, что это ужасно — я говорю о том, что это возможно. Это просто результат исследования. Я никому не рекомендую это использовать в таком виде в боевых целях.
jattach — то что нужно! Видел же ваш доклад, где вы его показывали. Идея вместо плясок с загрузкой библиотек и ковыряния в JDK вызывать jattach при установке плагина мне определенно нравится. Если-таки придется это исследование довести, то попробую сделать так, спасибо!
Не уверен, что код вызова jattach при установке плагина, получится более элегантным, но думаю, это то что нужно.
Замечу, что основная доля шаманства связана с тем, чтобы функционал упихнуть в плагин и сделать некий «движок для трансформаций». Мы можем легко и быстро написать новую трансформацию на Java на высоком уровне с помощью ByteBuddy, который сделает за нас много полезной работы, собрать стандартный atlassian-plugin и поставить его в JIRA — и вот трансформация применилась.
Понятно, что желание «быстро написать новую трансформацию» — это не нормальное желание, но в контексте статьи, мы именно этого и добиваемся) В этом основная ценность моего решения
По этой же причине я не уверен, что хороший вариант — это использование RedefineClasses — тут для каждой трансформации нужно писать отдельный платформозависимый код.
Что касается, Java 9. Последние версии JIRA работают на Java 8, и по моему мнению будут работать на ней еще долгое время после выхода 9ки. Поэтому этот вопрос я не исследовал. Возможно, модуль загрузить будет даже проще
Применяя ваш подход к моему примеру с назначением на группу:
jattach — то что нужно! Видел же ваш доклад, где вы его показывали. Идея вместо плясок с загрузкой библиотек и ковыряния в JDK вызывать jattach при установке плагина мне определенно нравится. Если-таки придется это исследование довести, то попробую сделать так, спасибо!
Не уверен, что код вызова jattach при установке плагина, получится более элегантным, но думаю, это то что нужно.
Замечу, что основная доля шаманства связана с тем, чтобы функционал упихнуть в плагин и сделать некий «движок для трансформаций». Мы можем легко и быстро написать новую трансформацию на Java на высоком уровне с помощью ByteBuddy, который сделает за нас много полезной работы, собрать стандартный atlassian-plugin и поставить его в JIRA — и вот трансформация применилась.
Понятно, что желание «быстро написать новую трансформацию» — это не нормальное желание, но в контексте статьи, мы именно этого и добиваемся) В этом основная ценность моего решения
По этой же причине я не уверен, что хороший вариант — это использование RedefineClasses — тут для каждой трансформации нужно писать отдельный платформозависимый код.
Что касается, Java 9. Последние версии JIRA работают на Java 8, и по моему мнению будут работать на ней еще долгое время после выхода 9ки. Поэтому этот вопрос я не исследовал. Возможно, модуль загрузить будет даже проще