Bitbucket Data Center 9.0 Early Access Program release

[YingranSun]

Can I check if EAP06 is shipped with atlassian-plugins-core:8.0.10 whereas it is 8.0.15 for Confluence eap? Will we get a new EAP with these changes?

Our next eap which will be released next week will have plugins version 8.0.15

[YingranSun]

I don’t get Bitbucket to store ‘build results’ when sent via build status api

Would you be able to provide the request body that you used? I’ll look into it

[YingranSun]

Hi, can you please confirm that org.osgi.framework is included in eap6?
I am having problems with DynamicModuleRegistration as it cannot autowire org.osgi.framework.BundleContext

These are the following packages that we export from org.osgi.framework in eap06:

org.osgi.framework
org.osgi.framework.connect
org.osgi.framework.dto
org.osgi.framework.hooks.bundle
org.osgi.framework.hooks.resolver
org.osgi.framework.hooks.service
org.osgi.framework.hooks.weaving
org.osgi.framework.launch
org.osgi.framework.namespace
org.osgi.framework.startlevel
org.osgi.framework.startlevel.dto
org.osgi.framework.wiring
org.osgi.framework.wiring.dto

Which should provide access to org.osgi.framework.BundleContext.

Have you added org.osgi.framework to your <Import-Package> ? Can you provide some more details on how to recreate this issue and I’ll look into it

[YannisArgyropoulos]

Hi,

com.atlassian.plugin.web.impl is removed, but the atlassian-plugins-webfragment upgrade guide seems to suggest that classes have moved there, for example
com.atlassian.plugin.web.DefaultWebInterfaceManager → com.atlassian.plugin.web.impl.DefaultWebInterfaceManager

@bplump

com.atlassian.plugin.web.impl

[YannisArgyropoulos]

Hi @YingranSun

I am not autowiring org.osgi.framework.BundleContext anywhere in my code, but inside /spring/atlassian-plugins-components-shared.xml I have this bean :

<beans:bean id=“dynamic-module-registration” autowire=“default” class=“com.atlassian.pocketknife.internal.lifecycle.modules.DynamicModuleRegistration”/>

Adding org.osgi.framework to Import-Package doesn’t change anything

[rlander]

This comes in because we spring scan Bitbucket which is used in our app.

This in theory has been updated to work on Platform 7, but I guess Bitbucket did something to exclude autowiring of BundleContext for apps?

Could somebody test pocketknife internally on Bitbucket 9? @TomRijnbeek

[YingranSun]

@YannisArgyropoulos @rlander Thank you for the extra information. I’ve been able to replicate the issue.

We will get this fixed in a future eap (may not make the next one though).

[heiko.mattes]

Hi,

I’m trying to make our plugin work in the new Bitbucket 9. We are setting user properties via the com.atlassian.sal.api.usersettings.UserSettingsService.updateUserSettings method.

Before, it used com.google.common.base.Function as a parameter, but this method is no longer available, and I changed the parameter to java.util.Function. In theory, nothing else should be needed to change, but after this changes, the user settings were no longer updated. So it seems this does not work as intended.

I tried going back to Bitbucket 8 and tried it with various versions (8.2, 8.15, 8.19), but none of it worked when using the java.util.Function method. Only the com.google.common.base.Function method was working.

This seems like I bug, but I’m wondering if I’m doing something wrong. Because shouldn’t this problem have been found already during the Bitbucket 8 lifecycle?

[YannisArgyropoulos]

Hi,

I’m also resolving the following classes witn @ComponentImport:

• com.atlassian.plugin.PluginAccessor
• com.atlassian.plugin.PluginController
• com.atlassian.plugin.event.PluginEventManager

However, com.atlassian.plugin and com.atlassian.plugin.event are not marked for removal (but some of their sub-packages are)

Could you please check if these are maybe excluded?

[UlrichKuhnhardtIzym1]

We’re using the Spring Java Config dep injection method. The OSGi bundler imports these packages in META-INF/MANIFEST.MF

Import-Package: ...,com.atlassian.plugin,com.atlassian.plugin.module,com.atlassian.plugin.osgi.external,
com.atlassian.plugin.web, ...

… and the packages are available after installing the plugin.

Can you check your target/classes/META-INF/MANIFEST.MF to see if your plugin is pulling in these osgi bundles.

[mkemp]

@rlander

I don’t think the platform offers any “fast paths” for module registration. A real world example I have is a customer with ~100 custom JQL functions in ScriptRunner. For each of these we have to register a module independently, which apparently blows away a whole bunch of caches, then move on to the next.

Even if we batch it all up into one XML string, I think the behaviour of how those modules actually get registered is identical (via pocketknife-dynamic-modules).

If you have any details to hand about the performance implications, e.g what caches get wiped, or hints to where I can dig in the source code, that would be handy.

It doesn’t, our products just aren’t designed for bulk module registration. Very much not easy to solve :L

The best thing I can offer you is profiling all the synchronous listeners to the PluginModuleEnabledEvents and seeing what’s slow. It’s also possible the customer has something else installed which is slow on these events.

If you find it’s some Atlassian code that’s problematic, we can fix that. Most of our caches are lazily rebuilt.

[mkemp]

@YannisArgyropoulos

Hi,

com.atlassian.plugin.web.impl is removed, but the atlassian-plugins-webfragment upgrade guide seems to suggest that classes have moved there, for example
com.atlassian.plugin.web.DefaultWebInterfaceManager → com.atlassian.plugin.web.impl.DefaultWebInterfaceManager

Hey, everything you need should be available by importing the OSGi service with the type DynamicWebInterfaceManager. The implementation is intentfully hidden to decouple.

If what you’re looking for isn’t available, please let me know along with the use-case so we can figure something out.

[YannisArgyropoulos]

I see, I got confused as there were mentions of DefaultWebInterfaceManager being moved, and I missed the part where you mentioned DefaultWebInterfaceManager is private and we need work with DynamicWebInterfaceManager instead
Many thanks!

[YannisArgyropoulos]

Thanks, this helped!

[metin]

We’re still stuck on com.atlassian.sal.api.usersettings.UserSettingsService.updateUserSetting not working with the java.util.Function object parameter.

Can anyone confirm they’ve got it working? Any comment from Atlassian perhaps?

[YingranSun]

@metin @heiko.mattes

We’re still stuck on com.atlassian.sal.api.usersettings.UserSettingsService.updateUserSetting not working with the java.util.Function object parameter.
Can anyone confirm they’ve got it working? Any comment from Atlassian perhaps?

Would you be able to provide a code example? What version of eap were you using? From testing with eap06 this method works and I am able to update user settings.

I tried going back to Bitbucket 8 and tried it with various versions (8.2, 8.15, 8.19), but none of it worked when using the java.util.Function method. Only the com.google.common.base.Function method was working.

I don’t think this method worked in BB 8 with java.util.Function, but this should be fixed in the eap.

[YingranSun]

9.0.0-eap08 has now been released!

This eap includes:

• the latest version of platform components (e.g. plugins v8.0.15)
• re-bundling of the Atlassian Troubleshooting and Support Tools plugin

The EAP is available as a standalone download in the following formats:

• zip file
• tar.gz file
• Linux 64-bit installer

[metin]

Alright, I admit our approach was to have it work on BB 8 before we test it on 9, because according to the API docs, it should actually work the same in BB 8.

So I guess we’ll have to implement some kind of a version switch for this.

[UlrichKuhnhardtIzym1]

I need to use apache httpclient (v4) in my app.

        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpclient</artifactId>
        </dependency>

But it’s a banned dependency, so it needs <scope>provided</scope>.
However the package is not available via OSGI export. When the plugin is installed it does not load properly because of missing package:
Unresolved requirements: [[com.izymes.plugin [144](R 144.0)] osgi.wiring.package; (osgi.wiring.package=org.apache.http.auth)]
Even with explicit ‘OSGI-Instructions’ the plugin cannot be installed

                        <Import-Package>
                            <!-- START: Apache dependencies for rest client-->
                            <!--    >> have to be imported to avoid OSGI bundle classloading issues -->
                            org.apache.http.auth,
                            org.apache.http.*,
                            *;resolution:="optional"
                        </Import-Package>

What is the recommended practice here? How can plugins make use of apache httpclient (v4), given that it’s a banned dependency that is unavailable from OSGI?

[YingranSun]

Alright, I admit our approach was to have it work on BB 8 before we test it on 9, because according to the API docs, it should actually work the same in BB 8.

I’d recommend testing with 9 since there are a good number of breaking changes between the versions. Please let me know if you encounter further issues