JSD API - Latest Version not available (3.4.1)

[jiraplugins]

HI,

link on https://developer.atlassian.com/jiradev/jira-apis states, that latest JIRA Service Desk Java API is Version 3.4.1.

Great! Trying to add it to the pom using Version String 3.4.1 like

        <dependency>
		    <groupId>com.atlassian.servicedesk</groupId>
		    <artifactId>jira-servicedesk-api</artifactId>
		    <version>3.4.1</version>
		    <scope>provided</scope>
		</dependency>

does not download Version 3.4.1 of JSD API. Latest version I found is 3.0.10, which is useless as it does not include support for Organizations.

Does anybody know, how to get the latest JSD API?

[rwhitbeck]

Hi @jiraplugins, I’m asking around internally to see if we can get you an answer.

[daniel]

JSD’s source isn’t available for anyone outside of Atlassian. https://jira.atlassian.com/browse/JSDSERVER-397

[jiraplugins]

I refer to this URL:
https://developer.atlassian.com/jiradev/jira-apis
I am NOT requesting for the source, I just want to use the Java API for JSD!

[daniel]

If you want the javadocs: https://docs.atlassian.com/jira-servicedesk/

[rwhitbeck]

@daniel if I understand the question @jiraplugins is asking how to access the specific version of the API for JSD. I assume this is in the SDK?

As an aside, Google thinks you’re talking in Turkish,

[daniel]

Opps. Sorry @jiraplugins . I’m still hunting but I’m guessing this is an oversight by the jira service desk team.

<dependency>
  <groupId>com.atlassian.servicedesk</groupId>
  <artifactId>jira-servicedesk-api</artifactId>
  <version>3.1.9</version>
</dependency>

I’m looking to see if there’s anything newer you can get.

[daniel]

Ok. so the bad news is that the latest public -api is:

<dependency>
  <groupId>com.atlassian.servicedesk</groupId>
  <artifactId>jira-servicedesk-api</artifactId>
  <version>3.2.0-038-01</version>
</dependency>

That said according to maven there is a 3.4.x artifact:

<dependency>
  <groupId>com.atlassian.servicedesk</groupId>
  <artifactId>jira-servicedesk</artifactId>
  <version>3.4.0-REL-0005</version>
   <scope>provided</scope>
</dependency>

And it does have the jira-servicedesk-api 3.4.0 api in it. So you should be able to depend on it to get hold of the 3.4 api (I haven’t tested though).

[rwhitbeck]

You are correct that these API’s aren’t currently available. A ticket has been raised to address this and I will update here once the API’s are available. I, unfortunately, don’t have an ETA on when that will happen.

[jiraplugins]

Hi Daniel,

thanks for your post, but it is not correct. Adding jira-servicedesk to the pom does NOT add the service desk api. Latest Version for servicedesk (not API) is 3.4.1. Which is not including the API.

[jiraplugins]

H rwhitebeck,

OK. your answer is now 6 days old. The documentation (developer.atlassian.com/jiradev/jira-apis) still shows Version 3.4.1 as latest for the API. Now my the question is:
a) are you going to change the documentation link?
b) are you going to provide the new API? If yes, when?
c) We build a native wrapper to get the missing functionality to retrieve organisations

And can you explain how the difference between documentation and realtity fits goes along with Atlassian promise concerning Major / Minor Api Versions and stability?

From our point of view, adding the API to the public documentation is the promise to deliver.

So, I would appreciate a definitive solution provided by Atlassian ASAP.

Thanks

P.S. Useless to mention here, that the wrong documentation was already reported more than 2 weeks ago…

[rwhitbeck]

Hi @jiraplugins,

The only answer I can provide to you is the one I already gave. I’ve alerted the appropriate team that the API’s are missing and a JIRA ticket was raised internally. I do not have an ETA on when that will be released.

I will follow up again today to try to get this escalated. Think of me as your advocate versus THE Atlassian representative for this issue.

That’s all I can answer.

Thanks,
Ralph

[jiraplugins]

Hi Ralph,

Thanks. Going deeper, we build a wrapper to get the CustomField used for saving the Organizations from Service Desk. Now it is getting even worth:
Trying to run an IssueSearch to find Issues assigned to a JSD Organizations throws the following exception:

java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at com.atlassian.servicedesk.internal.customfields.organization.CustomerOrganizationsSearchInputTransformer.getClauseFromParams(CustomerOrganizationsSearchInputTransformer.java:61)

Code Fragment:

SearchInputTransformer searchInputTransformer = issueSearcher.getSearchInputTransformer();
FieldValuesHolder fieldValuesHolder = new FieldValuesHolderImpl();
searchInputTransformer.populateFromParams(loggedInUser, fieldValuesHolder, actionParams);
Clause clause = null;
try {
SearchInputTransformer inputTransformer = issueSearcher.getSearchInputTransformer();
clause = inputTransformer.getSearchClause(getLoggedInUser(), fieldValuesHolder);
…
}
The problem seems to be, that the FieldValuesHolder contains the List of Organization -Ids as String Array, while the values have been saved as Number-Values in the database.

Jira Version: 7.3.3, JSD Version 3.4.0, JSD-API: 2.5.0

You should probably add this as well and open another ticket.

What would be the correct place to post bugs like this?

[saurabh.gupta]

How do you write code for jsd app without adding it as a dependency? Just asking

[jiraplugins]

If you want to write a jira plugin with optional and extended support for for JSD, proceed as follows:

a) during development add the correct JSD API reference in your pom (provided !)
b) create an abstraction service which encapsulates JSD functionality. You abstraction implementation needs to be:

• needs to check if JSD-API is available at all
• needs to ensure, that it works without exceptions in case JSD-API is not present

Thus you can not use any JSD service directly from your plugin, because this will break your plugin in case JSD is absent.

You can not use any OSGI injections in your Java services nor any JSD dependencies in your atlassian-plugin.xml. This will break you plugin in case JSD-API is not present.

Developing jira plugins using JSD Java API as optional part is not compatible with standard jira plugin development. Same applies for using for using JSD provided Rest services. These will fail as well unless you provided a JSD-API independent JSD-Application detection services.

Neither documentation nor examples do help here. You need to build this on your own.

To ensure compatibility ensure to consider: https://confluence.atlassian.com/adminjira/jira-platform-releases/jira-applications-compatibility-matrix

[saurabh.gupta]

I partially understand what you just said. Let’s assume the environment using JSD app will have JSD installed. Do I still need detection service? Even if you have detection service, how do you even develop app using java methods which doesn’t exist yet(JSD-API).

I found this page while searching for api -
https://maven.atlassian.com/maven-external/com/atlassian/servicedesk/jira-servicedesk-api/
Requirement is for 3.4.2 which has a weird string attached to it. At first I thought it’s a release branch but then I thought they can’t have so many release branches. So I am not sure if this is the one I can use 3.4.2-REL-0020. Also as java api doesn’t change much, can’t I use some other version of JSD as a dependency just to develop.

[jiraplugins]

HI,
your question seems to be out of topic here. Anyway, let me give you a quick answer:

The answer depends on what quality and type of plugin you want to develop and deliver.

1. You should be aware of general Java class loading mechanisms.
2. You should know how class loading is done Jira, which is based on spring
3. You should know how plugin loading and class access is provided to your plugin within jira

As far as I can see, the JSD-API is provided by the JSD application, which is not part of the Jira core but seems to run in a similar way like a plugin. Means: In case Jira core is running (which is NOT providing the JSD API) your plugin won’t start in case you are referencing “provided” services from your plugin. In case the Application JSD is running, you might be able to enable your plugin. If this behavior is acceptable and/ or desired, you can rely on injecting JSD services provided by JSD-API. If this is not the case for your plugin you need to build you own adapter and to remove all dependencies (to JSD-API) resolved during plugin enable process.

So, short summary:
If you don’t care, just go along with using direct JSD API dependency usage.

For comaptibility, use the lowest Version, you want to support with your pluign (check against the link I provided already).

E.g.: for Jira 7.3.8 and above use the following pom entries:

            com.atlassian.servicedesk
            jira-servicedesk-api
            ${jira-servicedesk-api.version}
            provided
        


  
        
        7.3.8
        3.5.2
        3.4.2-REL-0020 
...
    

If you need JSD installed in your dev environment add in addtion:

                         
.....
                                 jira-servicedesk
                                 ${jira.servicedesk.application.version}
                         
                        

in you maven-jira-plugin configuration section

You can get the API-Version string by inspecting loaded OSG -modules in the OSGI console of your development environment.

Hope this helps.

[t990922]

Hi there,

We have a situation where our add-on needs to:

1. Access specific services from JSD
2. Catch JSD ServiceDeskCommentEvent and prefer this event to regular Jira IssueEvent when SD is available. We catch the event as recommended by Atlassian: https://developer.atlassian.com/server/jira/platform/writing-jira-event-listeners-with-the-atlassian-event-library/

The add-on depends on JSD-API and here’s where the problems appear:
a) If we bundle it as provided then the add-on obviously wouldn’t deploy on a plain Jira because our source code makes use of JSD-API
b) If we bundle it as compile then our listener will not catch ServiceDeskCommentEvent - instead a regular IssueEvent will be caught.

I guess this can be workarounded by use of reflection (last resort) or two different codebases - one for plain Jira core and another for Jira with SD. None of the options is nice.

Perhaps you can suggest something else?

TIA,
Vladimir

[jiraplugins]

Hi,

• build a wrapper service
• try getting the required JSD Service using OSG lookup within a try catch block
• use a try catch block and check if you could receive the needed component
• handle result (may be null or something like this) correctly
• probably cache the fact that JSD is available (just for your convenience)

You do not want to maintain 2 code bases and there is no need. Reflection won’t help you in this case either.

Code fragment:

OrganizationService organizationService = null;

	try {
		organizationService = ComponentAccessor.getOSGiComponentInstanceOfType(OrganizationService.class);
	} catch (NoClassDefFoundError e) {
		logger.info("Jira Service Desk not present ...");
	}

To be clear: You can NOT use any of the JSD-API interfaces in the interface of your Service Adapter. This will not work in case JSD is not present in your system!

br,

iConcept Support

[t990922]

OrganizationService.class

Thanks for answering, I think this pointed me to the right direction. So, here’s the working result:

1. I created a separate class for listening to JSD Events.
2. The class is associated with EventPublisher in Jira listener class (destroy() and afterPropertiesSet() methods) if the SD is available.

This way Jira will not try to resolve JSD-API classes unless the SD is available and the plugin will start well without SD.

Hope this will save somebody days
Vlad