Bitbucket Data Center 9.0 Early Access Program release

UlrichKuhnhardtIzym1 · May 30, 2024, 9:18am

I suppose the migration patterns you established while migrating internal apps would be extremely valuable for vendors.
Are you able to share some recipes for the most common errors/problems you have encountered during migration?
I think this will save us lot of time since we don’t have to ‘re-invent the wheel’.

NandishSolanki · May 30, 2024, 10:34am

The Rest objects will be available again in a new EAP and not 9.0.0-eap04, right?

Also the osgi packages are no longer exported E.g. org.osgi.framework, Is that intentional?

rlander · May 30, 2024, 10:41am

org.osgi.framework is used widely within ScriptRunner, notably for access to the following classes:

org.osgi.framework.Bundle
org.osgi.framework.BundleContext
org.osgi.framework.BundleReference
org.osgi.framework.ServiceReference
org.osgi.framework.FrameworkUtil

ScriptRunner does a lot of dynamic work with bundles and service registration, the app simply cannot function without the ability to interface with OSGi directly.

rlander · May 30, 2024, 10:43am

atlassian-pocketknife-dynamic-modules also depends on OSGi classes, and is used within ScriptRunner.

Spring Scanner dynamic contexts are also utilised by ScriptRunner, which again depend on OSGi directly: Bitbucket

bplump · May 31, 2024, 7:41am

Are you able to share some recipes for the most common errors/problems you have encountered during migration?

I know we have a fair number of OpenRewrite recipes that we used to help automate a fair amount of the RESTv2 migration (which should apply to all products). I’ve asked about making these public.

bplump · May 31, 2024, 8:17am

The Rest objects will be available again in a new EAP and not 9.0.0-eap04, right?

The Rest* objects are going to take a bit of work to make public but we’re working on that now. I’d expect an EAP containing them late next week.

Also the osgi packages are no longer exported E.g. org.osgi.framework , Is that intentional?

Yes but we were clearly overzealous. The list of packages we plan to bring back in our next EAP is below. Let us know if there are more that are required. (cc @rlander)

org.eclipse.gemini.blueprint
org.eclipse.gemini.blueprint.blueprint.compendium.cm.config
org.eclipse.gemini.blueprint.blueprint.config
org.eclipse.gemini.blueprint.blueprint.container
org.eclipse.gemini.blueprint.blueprint.container.support
org.eclipse.gemini.blueprint.blueprint.reflect
org.eclipse.gemini.blueprint.bundle
org.eclipse.gemini.blueprint.compendium.cm
org.eclipse.gemini.blueprint.compendium.config
org.eclipse.gemini.blueprint.config
org.eclipse.gemini.blueprint.context
org.eclipse.gemini.blueprint.context.event
org.eclipse.gemini.blueprint.context.support
org.eclipse.gemini.blueprint.extender
org.eclipse.gemini.blueprint.extender.event
org.eclipse.gemini.blueprint.extender.support
org.eclipse.gemini.blueprint.extender.support.scanning
org.eclipse.gemini.blueprint.io
org.eclipse.gemini.blueprint.service
org.eclipse.gemini.blueprint.service.exporter
org.eclipse.gemini.blueprint.service.exporter.support
org.eclipse.gemini.blueprint.service.importer
org.eclipse.gemini.blueprint.service.importer.event
org.eclipse.gemini.blueprint.service.importer.support
org.eclipse.gemini.blueprint.util
org.osgi.dto
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
org.osgi.resource
org.osgi.resource.dto
org.osgi.service.blueprint
org.osgi.service.blueprint.container
org.osgi.service.blueprint.reflect
org.osgi.service.condition
org.osgi.service.packageadmin
org.osgi.service.permissionadmin
org.osgi.service.resolver
org.osgi.service.startlevel
org.osgi.service.url
org.osgi.util.tracker

NandishSolanki · May 31, 2024, 8:39am

Thanks for the update.

NandishSolanki · May 31, 2024, 12:34pm

Is there a chance we can get com.atlassian.sal.core.upgrade available to us?
We have had some issues in the past where running upgrades would end up in deadlock for some databases. The solution was to wait for AO to fully intitialise before running the upgrade tasks.

dkjellin · June 3, 2024, 12:47am

Hello,
I’m looking at making some of our Rest* models available. Currently the list of classes we’re thinking of making available is

AvatarAware
RestApplicationUser
RestDetailedUser
RestLinkedMapEntity
RestNamedLink
RestPerson
RestPersonalProject
RestProject
RestPropertyMap
RestPropertySupport
RestPullRequest
RestPullRequestParticipant
RestPullRequestRef
RestRelatedLinks
RestRepository
RestScope

I’m interested to hear if there any other rest models that is widely used and I will look at including them. These would all move into the rest-v2-api module as the rest-v2-model will remain DMZ and unavailable to third party developers.

christian.ott · June 3, 2024, 7:55am

Hi @dkjellin

Thanks for considering to include these models.

On a first glance, our plugins also use:

RestComment
RestCommit
RestBranch, RestRef
RestApplicationUser

There might be more.

What is the reason of keeping the model in DMZ?

remie · June 3, 2024, 8:22am

I’ll get back to you after we’ve finished our Confluence 9.0 and Jira 10 Platform 7 releases, as our Bitbucket app is less of a priority due to a smaller user base. It is of course highly possible that this will be too late and that you’ve already shipped Bitbucket 9 and our app will forever be broken, but I guess that is the consequence of doing Platform 7 for all major products in the same time span

NandishSolanki · June 3, 2024, 8:23am

Hi,
We make use of the following. We would need them to be included.

com.atlassian.bitbucket.rest.exception.UnhandledExceptionMapper
com.atlassian.bitbucket.rest.exception.UnhandledExceptionMapperHelper
com.atlassian.bitbucket.rest.user.RestApplicationUser
com.atlassian.bitbucket.rest.enrich.LinkEnricher
com.atlassian.bitbucket.rest.fragment.DefaultRestFragmentContext
com.atlassian.bitbucket.rest.fragment.RestFragments
com.atlassian.bitbucket.rest.fragment.RestFragmentsFactory
com.atlassian.bitbucket.rest.RestMapEntity
com.atlassian.bitbucket.rest.user.RestApplicationUser
com.atlassian.bitbucket.rest.comment.RestComment
com.atlassian.bitbucket.rest.pull.RestPullRequest

Thanks

christian.ott · June 3, 2024, 8:50am

It seems javax.xml.bind classes are not exported anymore.

It’s not on the list. Is the removal intentional?

dkjellin · June 4, 2024, 4:23am

Hello @NandishSolanki
I’ve got some good news for you.

LinkEnricher
DefaultRestFragmentContext
RestFragments

Are already included and should be in the already published EAP.
UnhandledExceptionMapper and UnhandledExceptionMapperHelper are no longer needed. From 9.0 apps only need to handle their own exceptions and need not worry about exceptions that Bitbucket provides. Or phrased differently you only need to worry about MyAppException as Bitbucket will now handle NoSuchRepositoryException without you doing anything.

The other Rest models you list are very likely to be included.

dkjellin · June 4, 2024, 4:28am

Hello @christian.ott
Those rest models are very likely to be included (the PR to add them is open as I type this).

What is the reason of keeping the model in DMZ?

To ensure that we can keep our promise to you to not break your apps in minor versions. We want to be more explicit about what is considered API and what is not, so you can trust that if you use something that we provide there will be no surprises outside of a major version release. It pains me to confess that for rest-models we have not been diligent enough at keeping this promise and we’ve had things go through that would have broken apps should have used that particular class. This way we can be clearer about our intention and you can trust that we will not break it without due warning.

UlrichKuhnhardtIzym1 · June 4, 2024, 6:39am

@dkjellin Can you confirm

com.atlassian.bitbucket.rest.RestMapEntity

UlrichKuhnhardtIzym1 · June 4, 2024, 8:38am

@bplump @dkjellin - so far there’s no explicit mention of which spring component approach is required. Officially all options are open

declare them in atlassian-plugin.xml via <component> and <component-import> elements,
declare them in Spring XML files via the <beans> and <osgi> XML namespaces, or
annotate them with @Component and Spring Scanner annotations such as @ExportAsService, and rely on the Spring Scanner runtime to generate the Spring bean definitions.
(Spring java configuration)[https://developer.atlassian.com/server/framework/atlassian-sdk/spring-java-config/]

Which ones will and which ones won’t work with Platform 7?

christian.ott · June 4, 2024, 8:49am

Would it be possible to allow javax.annotation again? I have a hard time banning it from the manifest.

UlrichKuhnhardtIzym1 · June 4, 2024, 9:41am

com.atlassian.plugin.webresource as a base package should not be removed, right?
The migration guide introduces com.atlassian.webresource.api.*

rlander · June 4, 2024, 12:25pm

What class are you referencing in the base package?

For us it’s WebResourceModuleDescriptor, but the upgrade guide has this suggestion:

WebResourceModuleDescriptor and UrlReadingWebResourceTransformerModuleDescriptor have been extracted as ModuleDescriptor interfaces and moved under the com.atlassian.webresource.api.decorator package.

So I guess we need to depend on these new interfaces, which doesn’t quite work because we actually initialise the underlying class to dynamically register modules @mkemp

Not sure I can trivially switch that over to XML registration with pocketknife, but will see.