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).
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.
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.
OK. your answer is now 6 days old. The documentation (Latest updates) 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…
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.
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?
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.
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.
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.
You should be aware of general Java class loading mechanisms.
You should know how class loading is done Jira, which is based on spring
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:
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.
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!
