Final touches before the Beta - Jira 8.0 EAP 08 … and some GA news

Jira Development Jira Data Center Announcements
, , , ,
1

Important note (26/11/2018)

Due to an unexpected issue with EAP 08, we’ve released a new version - 8.0.0-EAP08-fixed. Make sure you download this version of the EAP milestone.

If you use the maven.atlassian.com, download maven 8.0.0-m0025.
__

Sometimes it pays to wait for a good thing. To have a spotless beta, we’ve decided to ship EAP 08 with some remaining upgrades and fixes. But fear not - this time the milestone does not contain any breaking changes.

What’s inside?

We’ve upgraded several Jira platform components and enabled the option to postpone the mandatory reindexing. Read all about it in the Preparing for Jira 8.0 notes.

Where is it?

You can download the EAP milestone here. If you’re using maven.atlassian.com, make sure to get maven 8.0.0-m0024.

What’s next?

We’re nearly done wrapping the Beta for you, so you can expect it within the next 3 weeks. Feature-wise, Beta will be close to what we want to ship as Jira 8.0.

When’s the GA?

We’ve made updates to our plans and decided for the GA to happen towards the end of January 2019. This will give you enough time to prepare for the change and still enjoy the Xmas break.

Should you have any comments, you can post them here and we’ll be on them shortly.

3

Hi @mmichalak,
when the Beta is released, will you offer a download that includes both Jira Software and Jira Service Desk? Or else will you make one of them available as a downloadable application from within the other (the way it works for official releases, on the Applications admin page)? Because we need to be able to test against an instance that has both Jira Software and Jira Service Desk.

Also, I noticed an API change in the latest EAP that wasn’t documented: the com.atlassian.application.api.ApplicationManager#getApplication(com.atlassian.application.api.ApplicationKey) method now returns a io.atlassian.fugue.Option instead of a com.atlassian.fugue.Option.

Cheers,
David

4

Hey David,
AFAIK the plan for the Beta is to contain contain both - JSW and JSD.
Also, tx for the docu feedback - we’ll add the change :slight_smile:

5

Thanks @mmichalak.
There are actually other APIs that are also affected by this change (such as accessing entity properties), and the problem is that I in most cases you can’t identify the changes at compile time. For example:

final EntityPropertyService.PropertyResult propertyResult = issuePropertyService.getProperty(ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser(), issue.getId(), propertyName, new EntityPropertyOptions.Builder().skipPermissionChecks().build());
final EntityProperty entityProperty = propertyResult.getEntityProperty().getOrNull();

This will throw an exception at runtime when compiled against Jira 7 and run on Jira 8 (or vice-versa), even though it will compile just fine without a change, because while there is no explicit reference (import) to either io.atlassian.fugue.Option or com.atlassian.fugue.Option, the compiled code will hold an internal reference to either one of them to call the getOrNull() method.

This is a nasty change that will require extensive testing of our apps.

2 Likes
6

We have already released jira 8.0 beta. The JSD version compatible with the beta is JSD eap08 also released today.

7

Hi,
I met the problem that you described. Do you know any workarounds to fix it in the plugin?

8

@verenok you mean to build an app that’s compatible with both Jira 7 and Jira 8? There are two approaches:

  • build compatibility (adapter) libraries for Jira 7 and Jira 8 (compiling each against the appropriate Jira version) and call the right library based on the Jira version
  • use Java introspection to call the methods; since the only difference is in the return type it’s actually easy.
1 Like
9

thank you so much for the answer! Introspection is the best way if there will be only one bug(or a few) like this in the plugin.

10

@david2 Could I trouble you to expand a little bit on this:

We’re trying to avoid having two versions of our app, but our attempts at using introspection have so far been unsuccessful.

Here’s an original snippet of code affected by the issue:

final EntityProperty entityProperty = issuePropertyService
  .getProperty(user, currentIssue.getId(), "property-name-goes-here")
  .getEntityProperty()
  .getOrNull();

We’ve tried to replace it with something like this:

import java.lang.reflect.Method;

...

// Returns a {io,com}.atlassian.Fugue.Option, depending on JIRA 7 or 8
Object entityPropertyOption = issuePropertyService
  .getProperty(user, currentIssue.getId(), "property-name-goes-here")
  .getEntityProperty();

Method getOrNull = entityPropertyOption.getClass().getDeclaredMethod("getOrNull");

final EntityProperty entityProperty = (EntityProperty) getOrNull.invoke(entityPropertyOption);

…however we still get a compile error:

incompatible types: io.atlassian.fugue.Option<com.atlassian.jira.entity.property.EntityProperty> cannot be converted to com.atlassian.jira.entity.property.EntityProperty

I’m sure the solution is obvious, but I don’t have a lot of previous experience using introspection; so any help would be greatly appreciated.

11

This is what we use to access the property value from the return value of issuePropertyService.getProperty:

  public static <T> T getEntityPropertyOrNull(PropertyResult propertyResult) {
    try {
      Object option = propertyResult.getClass().getMethod("getEntityProperty").invoke(propertyResult);
      return option.getClass().getMethod("getOrNull").invoke(option);
    } catch (InvocationTargetException | NoSuchMethodException | IllegalAccessException var2) {
      throw new IllegalStateException(var2);
    }
  }
4 Likes
12

Thanks so much @david2, will give this a try. Really appreciate the help.

13

Works like a charm! Thanks for sharing.