The current plan is for it to go out with 10.0.1, apologies it couldn’t make it to 10.0.0 in time, that’s our mistake. Given the lack of continuity (between 9.x and 10.0) we’re classifying this a bugfix. We’re not porting to initial releases of other products since we’ve only heard this was used in Jira and there was an existing app built on this in Jira.
If something needs to change for whatever reason (I can’t think of any, but I mean totally unknown), I’ll let you know as soon as I do.
Hey,
The best I can do to explain how to convert, is by providing our i18n transformer as an example which does something similar.
It replaces i18n keys (‘variables’) with user strings (‘values’). The only thing it needs to make it stateless, is knowing the state of the plugin system (pre-encoded in the URL) and the locale used.
Another way to think about this is that one node in a DC cluster could contribute to the URL, and the another node needs to be able to figure out from those query parameters what should be done.
Well, I guess Velocity allowlist being enabled didn’t make it into Jira 10.0.0 after all, seeing from how Jira 10.0.0 behaves and from public docs:
For now, the Velocity method allowlist is in debug mode so that app developers can adjust to this mechanism and for us to complete the main allowlist and minimize the risk of issues. The debug mode will be disabled at the earliest in the upcoming Long Term Support release.
@AndreasEbert Yes, completing the main allowlist is not that easy (currently we have about 3k+ methods). For now we’re doing dogfooding and gathering logs for missed methods (and we’ve got some 
).
Hi,
I am currently trying to keep our plugin compatible between 9.2 and 10.0. I have encountered a problem with the new REST API, when trying to upload a file, which we process the file with a FilePart in the java class.
Now, thanks to the api changes, the FilePart got moved from the package ‘com.atlassian.plugins.rest.common.multipart’ to the package ‘com.atlassian.plugins.rest.api.multipart’. I am trying do resolve this, by having two different classes. One listening on one REST endpoint with the new API, and the other listening on a different REST endpoint with the old API. And then only call the correct endpoint, depending on the Jira version.
But when I try to now call the endpoint for the new API, I still get a ClassNotFoundException for the old com.atlassian.plugins.rest.common.multipart.FilePart, as if it tried to load the other class that should be only reachable under a different endpoint.
Now I’m wondering why this is not working. Am I doing something fundamentally wrong? Or how can I support file uploads via REST API simultaneously in Jira 9 and Jira 10?
@FilipeMiranda @ryan.brown, Fyi, we solved it in our Jira app by not using a <condition> at all, but a <data> (data-provider) instead, plus adapting our javascript-code a bit, like so:
var condition = WRM.data.claim('${pluginKey}:${moduleKey}.${dataProviderKey}');
if (!condition) {
return;
}
// other JS code be here
That works cross-version because the package of com.atlassian.webresource.api.data.WebResourceDataProvider didn’t change in Jira 10.
This may be an option for you, if you’re willing to take the downside that your JS is always included (for the relevant context). For us this is not a problem because the affected JS file is very small (<1kb).
Hi,
We’re trying to migrate the ResourceFilters. We’re using the Dynamic Binding.
We create the annotation
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface FilterDynamicBinding {
Class<?>[] value();
}
Then, we implemented the FilterDynamicBindingFeature
@Provider
public class FilterDynamicBindingFeature implements DynamicFeature {
@Override
public void configure(ResourceInfo resourceInfo, FeatureContext context) {
registerFilters(resourceInfo.getResourceMethod()
.getAnnotation(FilterDynamicBinding.class), context);
registerFilters(resourceInfo.getResourceClass()
.getAnnotation(FilterDynamicBinding.class), context);
}
private void registerFilters(FilterDynamicBinding annotation, FeatureContext context) {
if (annotation != null) {
Stream.of(annotation.value())
.forEach(context::register);
}
}
}
and then we put in the resource
@FilterDynamicBinding({ ContainerRequestDynamicBindingFilter1.class })
From the Doc, seems that the @Provider enables Atlassian REST plugin to discover and automatically register the filter, however, we’re not able to do debug in the FilterDynamicBindingFeature
Should we need to do other things?
Thank you
Can we get an ETA on Jira 10.0.1 @AndrzejKotas?
We won’t be releasing ScriptRunner for Jira until we have this version with the fixes we need.
Thanks a lot, I managed to fix our transformer with this example.
Hi,
We did the past days tests with applications links between Jira and Confluence.
| - | Confluence 8 | Confluence 9 |
|---|---|---|
| Jira 9 |  |
 |
| Jira 10 | |
|
I Also encountred this error message :
The remote application, ‘jira’, is running an older version of the Application Links plugin.
It will not be possible to create the remote end of the link from this application.
However both ends of the link can be created using the older process in ‘jira’.
Can you confirm this compatiblity matrix from your end.
please check this compatibility matrix - Jira Software 10.0.x upgrade notes | Atlassian Support | Atlassian Documentation
Cheers
Adam
Current plan is for 10.0.1 to be public by 09/09/2024*
*provisional subject to change
Can anyone from Atlassian (@AndrzejKotas ? @MaciejSzarecki ? @mkemp ?)reply to this?
It seems that checking the REST annotations causes all classes to get loaded and therefore attempting to resolve the import of both variants. We’re looking for a way to prevent this. Pre-load the appropriate class? Use an optional import? We’ve tried several ways, but to no avail.
Is it really supposed to work only with separate plugins for Jira 9.x and 10+?
We’re open to any suggestion in order to avoid that.
Hey together,
is this intended to work also with the oldest Jira version that is supported by Atlassian (9.3.0)?
<dependency>
<groupId>com.atlassian.jira</groupId>
<artifactId>jira-api-bom</artifactId>
<version>${jira.version}</version>
<scope>import</scope>
<type>pom</type>
</dependency>
If I use an older Jira version than 9.14.0, it does not compile, as it does not find it.
Cheers,
Marcel
No, the POM structure of Jira changed, we only recently added the BOM like you noticed.
Previously the following artifacts were mostly used by vendors:
If you haven’t requested source code yet for Jira, I recommend it.
There’s a lot of things that are hard to get working across major vesions, that’s part of why we recommend splitting the Apps into different versions.
Sorry without a stacktrace, I’m not exactly what you mean by loaded, whether that be classloader or from the plugin system?
Optional OSGi package imports for relying on our annotations will help.
Two load two entirely different set of REST resources is not trivial and will require two different packages and dynamically registering the REST plugin module with something like PKDM. It’s probably easier to use only JAX-B and javax. annotations to get a single version of REST resources working in both versions (don’t forget to add the REST v2 migration tag).
Hi team,
I just read about the removal of the greenhopper API in the future. I wonder how I will get access to sprint or issue events, or how to interact programmatically with them via Java.
Any clarification would be helpful. When I checked at the beginning of the year, I could not find any alternative to using greenhopper.
Best regards;
Christopher
Hi @chrschommer,
Where did you read about this? Could you please share?
I got this response to my support ticket (ECOHELP-46151) to fix the atlassian sdk 9.0.2 when using jira-core or greenhopper. Both got declared as deprecated and
isn’t meant to be used with P2 plugin development
I read about this in the marketplace clarity slack (see Slack)
A vendor got something about it from dev support:
jira-core is an internal library and isn’t meant to be used with P2 plugin development - this is not a supported scenario. I’d recommend that you update you app to use jira-api instead which is meant for public usage.
Similarly, greenhopper is deprecated for a while, and is not meant to be used in the latest versions anymore. You instead use jira-api