Hi, I have enhanced our REST v2 migration guide with more structured Migration steps and a list of Common problems and solutions that we encountered and resolved during our internal migration process.
1 Like
@UlrichKuhnhardtIzym1
It will move package, but the class com.atlassian.bitbucket.rest.v2.api.RestMapEntity is part of rest-v2-api and is available. It is part of the released EAP. For the rest 2 migration there will be a number of package changes (unfortunately) but the classes in the new package will be identical so the change will just be the import.
1 Like
All are supported, but it seems 1 is having some problems ATM
4 is the preferred option. Iāve done this most of the time and it can take a full day if thereās a lot going on.
Moving to 2 from 1 is relatively easy by stealing the majority of the generated XML from the transformed plugins cache in the application local home directory. Iāve done this when thereās been many hundreds of beans.
2 Likes
Itās very much supposed to be removed, everything you need should be under the API and SPI subpackages. The Web-Resource Manager needs a lot work and exposes many libraries that really other plugins shouldnāt need to be using the same version of (such as GSON and jgrapht).
Of course, we still want to support Apps, so if thereās a specific use-case you think isnāt possible or is hard to implement weād love to hear it. Creating a new thread here or creating a PLUGWEB ticket is all good
1 Like
Iāve created a skeleton plugin WP7 with atlas-create-bitbucket-plugin --maven-plugin-version 8.16.0 and made bitbucket version 9.0.0-eap4, swapped outdated dependencies based on atlassian-rest-v2-sample-helloworld
Iām running $ atlas-run-standalone --product bitbucket --version 9.0.0-eap04
- Helloworld loads and works (running
$ atlas-run-standalone --product bitbucket --version 9.0.0-eap04) - WP7 does not install and does not work. No Errors. Does not run on
$ atlas-run-standalone --product bitbucket --version 9.0.0-eap04oratlas-debug -v 9.0.0-eap04
I can see a difference in the OSGi bundle versions and tool versions.
I need to be able to build against bitbucket-maven-plugin instead of amps-maven-plugin because of Bitbucket specifics such as CSE etc.
Any help is greatly appreciated.
From what I could analyse at the time, ScriptRunner was one of the very few plugins that might any dynamic registration, most only do inspection.
Internally we have some BIIIG Jira plugins that would take tens of minutes to reinstall in development so they use Pocketknife Dynamic Modules to re-register just the web-resources.
Are yāall generating the definitions on the fly too, i.e. all the combinations cannot be known at compile time? Should still be entirely possible with XML generation even if itās a little bit clunky. Let me know how you go.
Of course, be aware that everytime a module is enabled or disabled, many caches in our products are invalidated and this causes a performance hiccup.
2 Likes
@mkemp, yes, problems indeed. In pure theory 1 works, but for all intents and purposes not in practice, because itās almost guaranteed that with one of the component-imports youāll also hit a grey-API-banned package coming from one of the super interfaces/classes. See my experience with Confluence 9 for more details.
We have a mix of both @mkemp, anything we can define upfront at compile time we do. ScriptRunner lets users configure custom web fragments inside the app, so for that use case we have to rely on dynamic registration.
Iām aware there are performance overheads, in fact I have a customer incident at the moment which is probably related to them.
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.
I need to add the java spring config equivalent of
<component-import key="executorService" interface="java.util.concurrent.ScheduledExecutorService"/>
On plugin install I get
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'importScheduledExecutorService' defined in OSGi resource[classpath:com/atlassian/plugins/rest/sample/v2/SpringBeans.class|bnd.id=135|bnd.sym=com.atlassian.plugins.rest.atlassian-rest-v2-sample-helloworld]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [java.util.concurrent.ScheduledExecutorService]: Factory method 'importScheduledExecutorService' threw exception; nested exception is java.lang.IllegalArgumentException: [Assertion failed] - this argument is required; it must not be null
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [java.util.concurrent.ScheduledExecutorService]: Factory method 'importScheduledExecutorService' threw exception; nested exception is java.lang.IllegalArgumentException: [Assertion failed] - this argument is required; it must not be null at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185)
The System OSGi Bundle exports java.util.concurrent and it looks like itās used by the helloworld plugin
For EAP04 I am not able to include org.eclipse.gemini.blueprint:gemini-blueprint-core because itās a banned dependency.
I have added the package to bitbucket-maven-plugin configuration like so
<banningExcludes>
<banningExclude>
org.eclipse.gemini.blueprint
</banningExclude>
</banningExcludes>
The plugin still wonāt build because:
[INFO] --- bitbucket-maven-plugin:8.16.0:validate-banned-dependencies (default-validate-banned-dependencies) @ wp7 ---
[INFO] validate banned dependencies
[INFO] Dependencies excluded from banning: [org.eclipse.gemini.blueprint]
[INFO] Platform version range: '[0,)'
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
make sure platform artifacts are not bundled into plugin
Found Banned Dependency: org.eclipse.gemini.blueprint:gemini-blueprint-core:jar:3.0.0.M01
Found Banned Dependency: org.eclipse.gemini.blueprint:gemini-blueprint-io:jar:3.0.0.M01
Am I stuck between a rock and hard place? Any advice how to work around this limitation is appreciated.
1 Like
Think they are meant to be back in the next EAP. But would be good to double check. Bitbucket Data Center 9.0 Early Access Program release - #27 by bplump
1 Like
The CSE example plugin on the Bitbucket 9 EAP04 branch does not install.
Solution:
Note to self: For CSE to work you must include META-INF/plugin-descriptors in the pom.xml bitbucket-maven-plugin instructions because thatās where the CSE builder puts it. It wasnāt obvious to me since I was using java-spring config.
Is there an estimate for the next EAP? We are currently blocked by the
org.eclipse.gemini.blueprint
org.osgi.framework
packages.
Given the very tight GA deadline in ~6 weeks, it would be great if we could move forward to rule out other potential blockers in our apps.
3 Likes
Hey @UlrichKuhnhardtIzym1 ,
Weāve updated the master branch of the template to make it compatible with the EAP and 9.0.0 - you should be able to use it now.
3 Likes
Hello @dkjellin!
Our app depends also on the following models:
- com.atlassian.bitbucket.dmz.rest.v2.util.RestPage
- com.atlassian.bitbucket.dmz.rest.v2.repository.RestMinimalRef
- com.atlassian.bitbucket.dmz.rest.v2.RestLinkedMapEntity
Please consider to include these models too.
Thanks
Iāve updated the main post with download links for Bitbucket Data Center 9.0.0-eap05. This EAP release contains the following changes:
Rest objects and APIs
The following RESTv2-compatible objects and APIs are now available:
AvatarAware
AvatarRequestHelper
CommentResolver
ConflictException
DiffContentFilterResolver
JsonStreamingOutput
NumberParser
PageHelper
PageRequestResolver
PluginNotAvailableException
PullRequestResolver
RepositoryResolver
RestApplicationUser
RestBranch
RestChange
RestComment
RestCommentThreadDiffAnchor
RestCommit
RestConflict
RestConflictChange
RestConstants
RestDetailedUser
RestDiff
RestDiffHunk
RestDiffLine
RestDiffSegment
RestErrorMessage
RestLinkedMapEntity
RestMinimalCommit
RestMinimalRef
RestNamedLink
RestPerson
RestPersonalProject
RestProject
RestPropertyMap
RestPropertySupport
RestPullRequest
RestPullRequestParticipant
RestPullRequestRef
RestRef
RestRelatedLinks
RestRepository
RestScope
RestTag
Bitbucketās REST objects and API can be found in subpackages of com.atlassian.bitbucket.rest.v2.api using the following Maven dependency:
<dependency>
<groupId>com.atlassian.bitbucket.server</groupId>
<artifactId>bitbucket-rest-v2-api</artifactId>
<scope>provided</scope>
</dependency>
More third party APIs available from Bitbucket
The following packages are now available to plugins:
com.sun.jarsigner
com.sun.java.accessibility.util
com.sun.jdi
com.sun.jdi.connect
com.sun.jdi.connect.spi
com.sun.jdi.event
com.sun.jdi.request
com.sun.management
com.sun.net.httpserver
com.sun.net.httpserver.spi
com.sun.nio.file
com.sun.nio.sctp
com.sun.security.auth
com.sun.security.auth.callback
com.sun.security.auth.login
com.sun.security.auth.module
com.sun.security.jgss
com.sun.source.doctree
com.sun.source.tree
com.sun.source.util
com.sun.tools.attach
com.sun.tools.attach.spi
com.sun.tools.javac
com.sun.tools.jconsole
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.packageadmin
org.osgi.service.permissionadmin
org.osgi.service.resolver
org.osgi.service.startlevel
org.osgi.service.url
org.osgi.util.tracker
4 Likes
@UlrichKuhnhardtIzym1 - The Platform 7 team published a document here with instructions on how to use the OpenRewrite recipes they developed to help ease migration to Platform 7.
2 Likes
(Edited to remove incorrect info)
I understand the missing javax.annotation is the reason for Spring Java config not working. Weāll add it to the next EAP.
3 Likes
Iām seeing this package has been exported from the system bundle since the first EAP. Version 2.3.3. Are you still having trouble finding them?
As with most javax dependencies, we now use the jakarta version of the dependency but the packages/classes it contains are identical:
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
</dependency>
1 Like
This is trying to say these dependency jars shouldnāt be included in your plugin jar file because you should be getting the class implementations from Bitbucket.
In your pom file, have you declared the dependency with provided scope (or test if you only need it for tests)?
<dependency>
<groupId>org.eclipse.gemini.blueprint</groupId>
<artifactId>gemini-blueprint-core</artifactId>
<version>3.0.0.M01</version>
<scope>provided</scope>
</dependency>
1 Like