End of support for Jelly Script

[Mirek]

On November Atlassian announced that:

Atlassian will end support for Jelly scripts in JIRA 6.4. If you are using Jelly scripts with JIRA, we recommend you move to Groovy Script Runner, which will provide you with a more flexible option.

Jelly Script End of Support Notes

• JIRA 6.3 will be the last major release to support Jelly scripts
• JIRA 6.3.x and earlier versions should continue to work fine with Jelly scripts
• JIRA 6.4 will not include Jelly.
• If you need an alternative to Jelly scripts, Groovy Script Runner is the suggested alternative that works with JIRA.

Source:

https://confluence.atlassian.com/display/JIRA/End+of+Support+Announcements+for+JIRA#EndofSupportAnnouncementsforJIRA-201411jelly

I personally really like Groovy Script Runner (thank yo Jamie for such a great and FREE! plugin) but I am wondering if this will be a 1 to 1 transition, why ending the support and how to prepare for the change. I am still using Jelly for couple of things mostly related to interact with the server (easy to set up based on a tags, stable, no need to check API for changes) and groovy to change things or execute based on the workflow action (post functions, emails, validation).

In general I would like to know if all things that are possible with Jelly Scripts will be possible when using Groovy Runner. I would like to hear some confirmation. In addition it would be great to have some few simple examples of the same scripts using both methods for people that do not know one of the options. @Jamie Echlin [Adaptavist], if you would like to give your 5 cents also on this topic it would be great. I am curious if you are aware about the change and how you think this could be handled. (Maybe you can think about a new feature Jelly to Groovy converter? )

[nick_ms]

As part our preparation to migrate to JIRA 7 we are working through some jelly scripts.

We have many jelly scripts, we have converted some of them using the JIRA Automation plugin. The rest we are converting to plugins.

I got a bit frustrated trying to convert scripts by hand so I have created a script that will convert a jelly script into a block of java/groovy code. The code requires a bit of post processing (until I do some more work on the script). This could be useful to anyone who wants to migrate existing scripts either to the JIRA Script Runner plugin or to use the code in a custom plugin.

It is still a work in progress. If anyone is interested I will make this publicly available.

[JamieA]

This page may also be useful: https://scriptrunner.adaptavist.com/latest/jira/recipes/jelly-migration.html

[Sune Mølgaard]

I may have a client who could have a need for this

[RahulG]

Hello Nick, even we are trying to convert scripts from jelly to groovy and I am writing this comment to check whether the script you created which converts jelly script into block of groovy code is publicly available ? If so kindly let us know so that we can use that. Thanks,

[JamieA]

Hi Mirek,

They did discuss it with me. Personally I can understand their reasoning... they have to maintain a lot of code for jelly when very few people (in percentage terms and absolute numbers) use it. You can do anything with jelly (if you have a masochistic tendency), and equally you can do anything with groovy. 

I suspect the main way it's been used is through people copying and pasting samples, eg the jelly escalation script, because trying to do anything that hasn't been done before is incredibly painful. 

For that particular example, the no-coding alternative would be Escalation Service in Script Runner. But I recognise people might want to write something that's identical to their jelly script. I will put together a direct translation of the examples here: https://confluence.atlassian.com/display/JIRA/Jelly+Escalation

But what are the other main cases for using jelly...? If I knew that I could provide some samples.

> no need to check API for changes

This is an entirely valid point. If you are majorly concerned about that I would suggest using Escalation Service, or the rest API with your own code hosted outside jira. Or there is a "curated" API available through other plugins, such as JJUPIN.

But the API of jelly does change, it must have done for eg to handle JQL over the old search requests (or maybe it never covered that).

Update 24 Sep 2015: There is information for people doing this migration here: https://scriptrunner.adaptavist.com/latest/jira/recipes/jelly-migration.html 

[Hitesh Ashar]

@Jamie Echlin [Adaptavist] https://confluence.atlassian.com/display/JIRA/Jelly+Escalation seems to have been deleted. Did you host your translation elsewhere? Please can you link to it?

[JamieA]

I don't think I ever did a direct translation. The "no programming" alternative is https://jamieechlin.atlassian.net/wiki/display/GRV/Escalation+Service.

[Hitesh Ashar]

@Jamie Echlin [Adaptavist] Awesome, works perfectly for me! Thank you :)

[B. Normann P. Nielsen]

Hi Jamie, just a few cents from here, as I am transferring some 10 Jelly scripts to Groovy/Escalation services: First, some logging from the Escalation service is really needed, at least for a run - if it fails it stacktraces, but a success does not leave a mark in either atlassian-jira.log or catalina.out (pr. default logging), so there is this "doubt" about "did it actually run as expected. The Quartz Crontab is the obvious choice for scheduling, but I do think its a bit "odd", it will not accept "10 * * * *" as a standard Limux cron, but require 6 arguments. "10 * * * * *" is accepted, but does not work, it stacktraces with " Scheduled job with ID 'JiraPluginScheduler:com.onresolve.scriptrunner.canned.jira.admin.EscalationService:job' failed java.lang.UnsupportedOperationException: Support for specifying both a day-of-week AND a day-of-month parameter is not implemented." PS: I know, RTFM :-) Third, as much as I love Groovy, it does concern me, that JIRA now as an "out of the box" product simply do not have a build-in script language (code controlled by Atlassian themselves), but that the 2 best options are 3rd party vendors - thats a bit scary, especially in the light of Scriptrunner could be a "not free" or limited-free, full-version-payable product in the future. I see that Adaptavist has picked up SR, thats good seen from a support/bug view, but as I stated, also a concern. Well, just had to get that of my chest, keep up the good work, as the Scriptrunner really has opened up JIRA possibilities for us (thumbsup) Regards, Normann

[JamieA]

Hi Normann, Thanks for that. I entirely agree that logging/reporting from escalation services could be much better. The crontab thing... it should be the same as elsewhere it's used in jira, eg a scheduled filter subscription. I hear you on the other points, but don't have anything useful to say on that subject right now, but thanks for taking the time to put that down. cheers, jamie

[Heiko Klump]

Comment is move to

https://answers.atlassian.com/questions/21627937

[JamieA]

I think I understand what you are asking, but it would be helpful if you could create a new question, preferably in English to get the most viewers.

[Heiko Klump]

Okay, thank you i will open a new question

[Deleted user]

If anyone here has lots of jelly scripts for running auto-transition/comment services that needs a groovy/script-runner replacement, I've put this together for us and thought it might be helpful to others.

https://bitbucket.org/stevenkling/jira-automation/src/f7e03a1d16c3ac40518750869e1cd84001d429b1/services/?at=master

Also, I am having one minor problem with this solution that I created a topic for here.  Would appreciate advice if any can spare it:

https://answers.atlassian.com/questions/16878877

[Bob Swift]

Administrator UI to Run CLI Actions is part of Run CLI Actions in JIRA is another alternative. Or, of course, just using JIRA Command Line Interface (CLI) or REST APIs scripts outside of JIRA.

While these alternatives will not replace everything that could be done via jelly scripts, many use cases can be covered this way.

[Jozef Kotlár]

It is interesting, that announcement is not mentioning as an alternative their own add-on [JIRA Automation|https://marketplace.atlassian.com/plugins/com.atlassian.plugin.automation.jira-automation-plugin]