We used the bitbucket.file-content.source.toolbar.secondary extension point to load the javascript. This is now a CSE and loads after the source has loaded, which means we miss a required event to set these annotations.
For now, we can still provide the functionality by loading the javascript in a different non-CSE webpanel.
We assume that more web-panel & web-items will be replaced by CSE.
Is it planned to officially allow plugins to add issue annotation and code coverage markers?
An alternative could an extended code-insights functionality that also works in the source view.
We have been using com.atlassian.applinks.spi.link.MutatingApplicationLinkService, and the parent ApplicationLinkService interface has only getter methods.
Could you please consider putting back com.atlassian.applinks.spi.link.MutatingApplicationLinkService and com.atlassian.applinks.spi.util.TypeAccessor ? Or provide a public API with CRUD methods to configure application links?
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'refRestrictionService': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: com.google.common.collect.Multimap referenced from a method is not visible from class loader
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:176)
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:101)
at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1899)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.getObjectForBeanInstance(AbstractAutowireCapableBeanFactory.java:1284)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:268)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:209)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:950)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:57)
at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:322)
at org.eclipse.gemini.blueprint.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:287)
at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:137)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
The app is using bitbucket-ref-restriction-9.0.0-eap09.jar and I do have access to some other classes in that package, like e.g. com.atlassian.bitbucket.repository.ref.restriction.RefAccessType
So we have now verified that the method UserSettingsService.updateUserSettings using com.google.common.base.Function has been deprecated, but the same method using java.util.function.Function, that should be used instead, has never worked properly until now in the 9.0.0 EAP when the old method was removed.
That leaves us with
Bitbucket 8.x offering a method with com.google.common.base.Function that works but is deprecated
Bitbucket 8.x also offering a method with java.util.function.Function that does not work, so cannot be used
Bitbucket 9 offering only a method with java.util.function.Function (that works)
So we need to use both method signatures depending on the Bitbucket versions, but therefore have a dependency to com.google.common.base that cannot be resolved in Bitbucket 9.
This happens because RefRestrictionService exposes Guava types in its method parameters.
With platform 7 apps are forced to bundle Guava, autowiring will blow up in this case, as there are conflicting classloaders for the Guava types, preventing creation of a JDK proxy for the service interface.
We can hack around this by grabbing an instance of the bean by other means, but ideally Atlassian would remove Guava from this interface entirely.
We need to have Conditions for the new CSE extension point bitbucket.file-content.diff.toolbar that have access to the commitRange and the path of the currently opened file.
The relevant object as passed to the client-side-condition (before the CSE) looked like this:
The context of the new CSE misses these objects and only provides repo/project plus some metadata. See file-toolbar-extension-context/index.jsx:10 of the Bitbucket sources.
Please bring this information back to allow the same functionality as before
Iād like to give an update about our plans for the final Bitbucket 9.0 release. At this point, we are on track to release Bitbucket 9.0 on 23 July.
We understand that your Bitbucket apps may not be ready given the changes required in early EAPs and the competing work required to migrate Jira and Confluence apps for their major releases. As some consolation, we donāt expect much adoption of Bitbucket 9 until the first Bitbucket 9 LTS is released several months from now.
The dev team will be focusing on removing any issues blocking you from making progress on your app migration. If you hit any blocking issues, please let us know ASAP and weāll aim to get you an answer or fix as quickly as possible. Weāve got a strong team of Bitbucket developers monitoring this thread and following up on issues.
Weāre currently working on the following issues:
An issue using RefRestrictionService
An issue using MutatingApplicationLinkService
Missing context in the bitbucket.file-content.diff.toolbar CSE condition
Some more docs to assist you with REST V2 migration
I know this isnāt the answer many of you were hoping for but I hope this provides some certainty to help you plan your app migration.
I get the following exception when I try to use a condition ( based on com.atlassian.plugin.web.Condition) on a clientside extension.
Caused by: com.atlassian.plugin.PluginParseException: Unable to load the module's display conditions:
Cannot load condition class: ch.mibex.SomeEnabledCondition.
Only classes extended com.atlassian.webresource.spi.condition.UrlReadingCondition are supported.
Please migrate your conditions to the com.atlassian.webresource.spi.condition.UrlReadingCondition class. https://developer.atlassian.com/server/framework/atlassian-sdk/stateless-web-resource-transforms-and-conditions
It looks a bit like the change mentioned here but in that document it states that com.atlassian.plugin.web.Condition is still supported for some extensions types.
The CSE docs explicitly mention the web sections which should be able to use the Condition class.
Iāve raised a fix for UserSettingsService.updateUserSettings with java.util.function.Function for the next Bitbucket 8.x bugfix releases, but that wonāt be released for another month and a bit. Also its not guaranteed that a customer will upgrade to a version of BB8 with the fix.
I think youāll have to have 2 different versions of your app, one for Bitbucket 8, and one for Bitbucket 9.
Thank you very much, but as you say yourself, that wonāt help anyone at all, so Iād say better save your time for other things.
The problem is that the function has been deprecated without a working alternative over multiple releases, and nobody seems to have noticed that. The only fix that would actually help would be to re-introduce the deprecated method in 9.0.0 and keep it there for a few versions with both method signatures working.
However, weāre now working on an internal work-around using reflection. Itās not what I call a neat solution, but having two versions of our app wouldnāt be neat either, so that way we can hopefully keep one version of our app.
Does this mean you will also add com.atlassian.applinks.api.ApplicationType and com.atlassian.applinks.spi.util.TypeAccessor ? I think weālll need them to use MutatingApplicationLinkService
Weāve just noticed that in the latest 9.0.0-eap10 itās no longer possible to select Dark Theme. Nothing happens when clicking on the Theme menu entry.
When can we expect a stable beta release with all the planned changes for final compatibility testing?
As you see from my colleagues @christian.ott questions, we try to test and give early feedback and appreciate fast EAP cycles. But for a final testing for all our apps, a more stable Beta with a grace period until the final release would be very valuable.
We are also puzzled, that Atlassian is planning to publish a release, but expect at the same time customers not to adopt it. What is the purpose and value for Atlassian and the ecosystem? Would it be not better to have stable Beta releases planned, so that partners, vendors and interested customers can start testing in their staging environments and can give valuable feedback, instead of an unusable public release?
Then why release Bitbucket 9.0, when you are well aware that a good fraction of the app ecosystem will most likely be broken? The early adopting customers will most likely ask us, the app vendors why our apps arenāt ready, and we will sit with the blame. Why not push the deadline with an extended beta period to make sure that the ecosystem is caught up with the disruptive changes of platform 7? Then customers are still able to install the beta on their dev environments, but no one will receive any false impression that things are actually ready or stable.
