Jira Service Desk is deprecating com.atlassian.fugue in 3.15

JSM Development JSM Data Center Announcements
, ,
1

Hi everyone,

Today we published a deprecation notice for the use of com.atlassian.fugue in Jira Service Desk 3.15.

I strongly recommend you read the full deprecation notice here. In summary:

We’ll be deprecating the use of com.atlassian.fugue in Jira Service Desk 3.15.
In Jira Service Desk 4.0, we’ll be updating our APIs to use Core Java Data types and Exceptions.
You’ll need to update any scripts, integrations or apps that make requests to endpoints returning com.atlassian.fugue with the release of Jira’s 8.0 Early Access Program (EAP).
In accordance with the Java API Policy for Jira, support for com.atlassian.fugue will continue to exist and work in the following minor release, but will be removed in the next major release.

Regards,
Lachlan Goodhew-Cook
Senior Developer, Jira Service Desk Team

1 Like
2

Hi @lgoodhewcook,

this will obviously have a serious impact on both app vendors and customers who created their own scripts (e.g. Groovy scripts in ScriptRunner or JMWE).

While customers will “simply” need to update their scripts when they upgrade to JSD 4.0, how about app vendors? We obviously don’t want to have to “branch out” development for Jira 8 + JSD 4.0 and maintain two lines of code (we all know migration to Jira 8 will be very gradual). Do you have an approach to recommend for maintaining dual compatibility with both JSD 3.x and 4.0 in a single app version?

2 Likes
3

Hi @david2 ,

Yes this will have an impact on vendors. Luckily it will only affect the consumers of the Java API so if they’re using REST APIs for their scripts or add-ons then they have nothing to worry about.

For consumers of the Java API that want to simultaneously support both versions of the API I would suggest a bridge layer that would decide what version of the API to use and converting it to your own internal preference. I have anecdotal evidence that quite a few vendors already have similar and we even do something like that for Portfolio for Jira.

So abstracting calls to the JSD API through your own wrapper

       Your code
           |
           |
      JSD Bridge
           |
     +------------+
     |            |
 JSD 3.x       JSD 4.x

The choice of whether you convert the exceptions to Either<AnError, T> like it used to be or convert the Eithers to Exceptions is entirely up to the vendor and how they want to handle things.

Those might look something like

try {
	ServiceDeskComment serviceDeskComment = serviceDeskCommentService.getServiceDeskCommentById(user, commentId);
} catch (ServiceDeskServiceException e) {
    return Either.left(new AnError(ErrorMessage.builder().message(e.getMessage()).build(), HttpStatusCode.INTERNAL_SERVER_ERROR));
}

or

either.fold(err -> {
    throw new ServerException(err.getMessage());
}, Function.identity());

Both of which I’d put in some kind of helper to help keep the duplication down.

Hope that helps

Lachlan Goodhew-Cook
Senior Developer, Jira Service Desk Team

2 Likes
4

Hi @lgoodhewcook,
thanks for the detailed answer.
So basically we need to develop three new JAR libraries - the JSD bridge that will load either the 3.x or the 4.x implementation based on the JSD version (which I assume we read from the UPM), a JSD 3.x implementation that depends (in the Maven sense) on the JSD 3.x API, and a JSD 4.x implementation that depends on the JSD 4.x API, correct? That’s a lot of work though - don’t you think that’s something Atlassian should be providing, like the user compatibility library Atlassian provided with the Jira 7 release?
Cheers,
David

3 Likes
5

Hey @david2,

Your understanding of what needs to be done with the libraries is spot on. You’ll only need to implement interfaces for the functions you want to consume. We appreciate the effort on your part to set this up and are here to offer guidance through the process.

Atlassian has no plans at the moment to provide a library supporting development for multiple versions of Jira Service Desk at once.

Regards,
Lachlan Goodhew-Cook
Senior Developer,
Jira Service Desk Team

6

Hi @lgoodhewcook,

We are offering a JSD automation then action within our Automation with AWS (Jira) app. This implies implementing the respective interfaces for the action, visualizer and validator classes, and the fugue removal resulted in these interfaces changing (both namespace and method signatures).

Thus we have to provide alternative implementations of these interfaces depending on the JSD target version, and we can’t use the bridge approach you outlined in your answers to David, as the implementing classes we have to declare in the plugin descriptor need to match those interfaces.

Question: We would still prefer to be able to ship only one artifact of our app - do you see any option to do so?

Things we have contemplated for this:

  • Separating the action implementations into alternative OSGi bundles within the apps OBR, so that they can be activated based on the JSD version in play - not sure if the JSD OSGi usage would allow for this?
  • Registering the then action programmatically rather than in the plugin descriptor (to allow declaring different implementation classes) depending on JSD version) - not sure if this is possible at all?
    • Edited to add: Or a variation of this - are there any conditions/special attributes for the action declaration in the plugin descriptor that would allow us to reference different classes depending on JSD version (seems unlikely, but I have not found a reference documentation for those declarations, hence not sure)?

Any insights, tips or alternative approaches highly welcome.

Thanks,
Henrik

PS: The Creating automation rule components guide should probably be updated to mention the JSD 4 changes.

7

Hi Henrik,

We believe the clearest solution is to ship two different artifacts. But if you’d still prefer to ship one artifact, these are my views on the two solutions you suggested.

  1. Two OSGI Bundles - having a separate OSGi bundle for 3.16 and 4.0 bundled in one OBR will work. The only problem I see, is that whenever someone installs your app, they’ll get a warning message saying ‘one bundle was not activated, as it couldn’t find the OSGi requirements’.

  2. Registering the then action programmatically - this should be possible, but we’ve haven’t tested this before. For that reason, I wouldn’t suggest this approach.

Conditions can be added to “then actions” just like web fragments, but they don’t give you an option to reference different classes.

We are currently working on updating the Creating automation rule components guide at https://developer.atlassian.com/server/jira/platform/creating-automation-rule-components/ for Jira Service Desk 4.0.

Thanks,
Kunal Kanojia
Senior Developer
Jira Service Desk Team

1 Like
8

Hi @kkanojia

Thanks for the detailed answer, much appreciated!

We had experimented with the separate OSGi bundle approach in the meantime, and it does indeed work so far - however:

I am worried about this, but can not confirm it so far - we don’t get any warning, neither from the UPM, nor within the main Jira logs.
My current assumption is that this is due to our test approach operating with three bundles, one for the main app (declaring, among other stuff, the then action itself), and two for the different JSD version implementations. Both of these ‘sub’ bundles declare the same export package (imported by the main bundle), and only differ in terms of their required import packages, i.e. the JSD 3.x or JSD 4.x ones (and the actual implementation classes, of course).
Since (as I understand it) their installation is only triggered by the main bundle having the import package declaration, OSGi is trying to find a suitable bundle exporting the package, and finding only one which it can even try to install, given their respective JSD dependencies, thus the one that would trigger such as message is not even attempted to be installed.

:grey_question: Does this make sense or am I missing/misunderstanding something?

9

Hi Henrik,

Your approach makes sense. I am glad that you were able to make the change and test it as well.

Thanks,
Kunal Kanojia
Senior Developer
Jira Service Desk Team

1 Like
10

hi @hopel,

Would you be able to share a snippet of the plugin configuration showing how to create separate OSGI bundles within the same OBR? We’ve run into the same issue with THEN actions and would appreciate any help you can offer.

Kind Regards,
Robert Courtney