I wanted to release an application dedicated specifically to Jira >= 9 DC, can you give me some tips on how to process such an application in Atlassian Marketplace?. Does Atlassian already have any official (or unofficial) release process for Jira 9?
The EAP02 contains a major regression related to Jira dashboards. It’s basically not possible to configure a dashboard anymore. As soon as you try to drag & drop any gadget, it remains “hanged” in a weird position.
Is this problem known? If not, can we report this anywhere?
Hi,
this change Jira 9.0 has a release candidate! - #16 by FilipNowak?
will cause to be necessary to publish a separate artifacts for Jira 8 and 9 → by our side it is a huge problem.
Any ideas how to implements adapters that will adopt jira web actions for Jira 7 i Jira 8 ?
Hi,
Reply to Jira 9.0 has a release candidate! - #26 by hirota.takayuki.
You can replace it with this one - "issue/createmeta/projectKeyOrId/issuetypes/issuetypeId. jira-rest-java-client-core has a method for it but it is not parsing the id correctly and it is null. It is expecting id but in reality it is fieldId. The method is IssueClient.getCreateIssueMetaFields.
You can do something like that:
Jira 9 EAP 02 requires annotations like “@SupportedMethods({RequestMethod.GET})” for all actions that use non-POST methods. You mentioned that there is no additional compatibility package is planned for Jira 8. This makes it impossible to create plugins compatible with both Jira 8 and Jira 9.
So we have only 2 options:
Do not use GET actions or
Create separate plugin versions for Jira 8 and Jira 9.
Could you please confirm that if we unable to exclude GET actions we have only the second choice – separate plugin versions for Jira 8 and Jira 9?
Separate plugins for Jira 8 and Jira 9 are simply unacceptable. We have been able so far to have a single version supporting Jira from 7.0.0 to the latest Jira 8, we need to be able to continue down that path with Jira 9.
Please escalate internally.
Hello @denis@piotr.patrzek1@david2 ,
May I ask: are you compiling the plugin against Jira 9.0 or the older version?
In case the plugin is compiled with Jira 9.0, it can be run on Jira 8.x too if we are talking only about the annotations. They just won’t have any behavioural effect. Could you please explain what kind of solution would satisfy your needs?
We’ll return to this topic, and analyze the problem after we get the feedback.
It would be typical for people to compile with the lowest version of Jira their app supports, otherwise you run the risk of accidentally using classes/methods not present in older versions.
@FilipNowak we compile against the oldest version we support (currently 7.3.0). When Atlassian introduced breaking changes like this, a compatibility library was usually provided. There are cases where we have to use workarounds, like introspection, to support newer APIs that were not backward-compatible, but here the approach would not work.
@FilipNowak
The same as above – we use the lowest supported version (currently 8.0) to build the plugin. This guarantees that our code does not contain anything incompatible with old Jira versions we support.
I tested your solution (build for Jira 9 and run in Jira 8) – and it seems working. Thank you.
This is not an ideal solution as it requires more attention about the code (because it is easy to use something from newer Jira version and break the plugin on old supported versions), but it is definitely better than having different plugin versions, and so it looks acceptable for us.
Unfortunately, we can’t build for Jira 9 (nor even Jira 8) without some major refactoring, as our code is written for Jira 7 (with aforementioned tricks to support Jira 8)
We are currently facing an error related to the way we are loading Javascript files.
So, basically, our velocity file is rendered before the Javascript we need.
We have a velocity file where we load the web resource with the javascript we need and also we have a form.
At the end of the velocity file, we invoke a function from Javascript, and on the console browser, e got an error saying the function we invoked is not defined.
Furthermore, we also have another error related with AJS and the error is:
AJS.$ is not defined.
Does anyone face the same problem with the JIRA EAP 9(version 02 and version 03)?
I am trying to update some browser tests against 9.0.0-m0009.
I noticed the gg or , quick access menu appears to be broken for a freshly loaded browser session.
For example, starting from the login screen, fully clear your browser cache, then log in and try to use the gg key. No menu will show, but if I refresh the browser, it will start working.
It seems the EAP has some issues loading the standard Jira JS resources at the required time.
Hey @denis@FilipNowak,
we have exactly the same problem with the required @SupportedMethods annotation.
We saw that it will not break the app itself, if you compile it against Jira 9.0 and install the app on Jira 8 or older.
But we always run our integration tests to the lowest supported version of our app, to make sure that nothing is broken there. In addition to that, we develop against the lowest supported version as well. The reason is, that we want to avoid the direct access to functions, that are available in newer versions. If we want to use these new functions, we have to access them via Java Reflections, to make our app backward compatible. If we develop against Jira 9.0 it’s much more unsafe and the probability is much higher, that somebody uses new functions that breaks the compatibility to lower Jira versions.