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?
This was a mistake on our end. I’ll make this available in the next eap so you should be able to use this with <provided> scope
@bplump given that we are now heading to yet anther EAP, I strongly urge you to adjust the planning of the GA release date
As mentioned here, you expected to have it complete & ready to ship in late June. But we are still in EAP stage with 80+ comments from partners since your last update and still there are new issues being found.
I would really like to ask from Atlassian that they adjust their policy to plan the release 8 weeks after the last EAP. That means that as long as partners are finding severe issues that are blocking apps from being able to adopt Platform 7, and new EAPs are required to address those issues, that there will not be a GA releases within the next 8 weeks.
We should avoid a situation in which the GA version is released 4 days after the last EAP just because there is a fixed date.
This is more pressing because we are entering summer vacation period in the northern hemisphere which will impact staffing for vendors.
I understand Atlassian operates with autonomous teams, but please also be mindful that there are currently 5 products that have Platform 7 GA release dates planned in July-August, and each of these products are still heavily in EAP mode because of issues found by partners.
It would be great if Atlassian recognises the amount of work partners are already putting into Platform 7 and appreciates what you are asking from partners.
When I start using 9.0.0-eap08 I get lots of
java.lang.RuntimeException: java.lang.ClassNotFoundException: org.glassfish.jersey.internal.RuntimeDelegateImpl
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:129)
at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:96)
at javax.ws.rs.core.Response$ResponseBuilder.newInstance(Response.java:839)
at javax.ws.rs.core.Response.status(Response.java:567)
at javax.ws.rs.core.Response.status(Response.java:578)
at runtime.
The dependency:tree for eap08 does NOT provide any dependencies for jersey glassfish implementation.
[INFO] +- com.atlassian.plugins.rest:atlassian-rest-v2-plugin:jar:8.0.3:provided
[INFO] | +- (com.atlassian.plugins.rest:atlassian-rest-v2-api:jar:8.0.3:provided - omitted for duplicate)
[INFO] | +- com.atlassian.plugins.rest:atlassian-rest-v2-internal-api:jar:8.0.3:provided
[INFO] | \- (com.atlassian.plugins:atlassian-plugins-osgi-javaconfig:jar:0.6.0:provided - omitted for duplicate)
[INFO] +- com.atlassian.plugins:atlassian-plugins-webresource:jar:7.0.2:provided
Where as eap06 does provide them and the plugin works.
[INFO] +- com.atlassian.plugins.rest:atlassian-rest-v2-plugin:jar:8.0.0:provided
[INFO] | +- (com.atlassian.plugins.rest:atlassian-rest-v2-api:jar:8.0.0:provided - omitted for duplicate)
[INFO] | +- com.atlassian.plugins.rest:atlassian-rest-v2-internal-api:jar:8.0.0:provided
[INFO] | +- (jakarta.ws.rs:jakarta.ws.rs-api:jar:2.1.6:provided - omitted for duplicate)
[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.42:provided
....
Looks like a regression, any advice is appreciated.
I would like to support @remie 's motion, and re-iterate on my previous post:
The (generous) 8 weeks countdown for the BB9 GA release should start when app developers and vendors are provided with an EAP version that is not fundamentally flawed and thus making it impossible for vendors to provide a working version of their app due to these flaws.
What does fundamentally flawed mean? IMO it’s when a problem is reported and acknowledged by ATL staff like this or a (potential) regression like this.
In the spirit of “Impossible Alone! -We’re at our best when we work as a team.” we are building our business on transparency and fairness and I am sure this will ensure mutual success for Bitbucket customers, Atlassian and vendors.
+1 for this sentiment, the same problems plague Jira, there have not been any meaningfully useful EAPs for Bitbucket up to this point.
Atlassian can’t claim app vendors have had the full duration of the EAP cycle to get ready, if every EAP released is fundamentally broken.
At present it seems unlikely our app will be ready for Bitbucket 9, in the end our mutual customers are those that will suffer from aggressive timelines.
With eap8 I still have issues resolving com.atlassian.scheduler.cron.CronExpressionValidator with @ComponentImport
Could you please check that this is exported as a bean, and if not, include with the next eap?
@TomRijnbeek
It is intended that atlassian-rest-v2-plugin no longer provides jersey. We have verified that RESTv2 works with eap08 on a test external plugin, however there may be cases that we’ve missed.
Would you be able to provide more information on how you triggered this exception? If you can provide a code sample that can replicate the issue, that would be awesome.
The exception was thrown for unit tests and I didn’t validate integration tests. You are correct that EAP08 REST APIs work for plugins when testing endpoints on a running instance 
.
For Unit tests to ‘find’ a javax.ws.rs.core.Response runtime implementation I added
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-common</artifactId>
<version>2.42</version>
<scope>test</scope>
</dependency>
to the pom.xml
Apologies for the false alarm, perhaps others come across a similar problem and this update is of help.
Thanks for raising this, this will be resolved in the next eap
This eap:
com.atlassian.scheduler.cron.CronExpressionValidatorThe following packages have now also been made public:
com.atlassian.http.method
com.atlassian.http.mime
com.atlassian.http.url
com.atlassian.httpclient.api
com.atlassian.httpclient.api.factory
org.apache.http
org.apache.http.annotation
org.apache.http.auth
org.apache.http.auth.params
org.apache.http.client
org.apache.http.client.cache
org.apache.http.client.config
org.apache.http.client.entity
org.apache.http.client.methods
org.apache.http.client.params
org.apache.http.client.protocol
org.apache.http.client.utils
org.apache.http.concurrent
org.apache.http.config
org.apache.http.conn
org.apache.http.conn.params
org.apache.http.conn.routing
org.apache.http.conn.scheme
org.apache.http.conn.socket
org.apache.http.conn.ssl
org.apache.http.conn.util
org.apache.http.cookie
org.apache.http.cookie.params
org.apache.http.entity
org.apache.http.entity.mime
org.apache.http.entity.mime.content
org.apache.http.impl
org.apache.http.impl.auth
org.apache.http.impl.bootstrap
org.apache.http.impl.client
org.apache.http.impl.client.cache
org.apache.http.impl.client.cache.ehcache
org.apache.http.impl.client.cache.memcached
org.apache.http.impl.conn
org.apache.http.impl.conn.tsccm
org.apache.http.impl.cookie
org.apache.http.impl.entity
org.apache.http.impl.execchain
org.apache.http.impl.io
org.apache.http.impl.pool
org.apache.http.io
org.apache.http.message
org.apache.http.params
org.apache.http.pool
org.apache.http.protocol
org.apache.http.ssl
org.apache.http.util
Why make the Apache HTTP libraries accessible? Does the Bitbucket API itself have methods that take in types from these classes?
I’d expect vendors to be bundling that library, we are on platform 7. Making it OSGi accessible is not consistent with Confluence 9.
If it shows up as a banned dependency, that is a bug in AMPS, which really does not play nicely with platform 7 at all.
Atlassian should really check the SDK does not ban dependencies that are removed as grey APIs…
I run into an issue when using custom icons in the new clientside-extensions on the repository.
The new extension-point-wrapper.jsx does runtime propType tests on the provided attributes. For iconBefore and iconAfter this expects a node proptype which can be one of
export type ReactComponentLike =
| string
| ((props: any, context?: any) => any)
| (new(props: any, context?: any) => any);
export interface ReactElementLike {
type: ReactComponentLike;
props: any;
key: string | null;
}
export interface ReactNodeArray extends Iterable<ReactNodeLike> {}
export type ReactNodeLike =
| ReactElementLike
| ReactNodeArray
| string
| number
| boolean
| null
| undefined;
The problem is that it’s also possible to pass a function which returns a custom react node with an SVG. See getIconPropsFromAttrs in
export const getIconPropsFromAttrs = (iconAttrs) => {
let iconProps;
// Atlaskit icon name or a custom React node with SVG
if (isString(iconAttrs) || isFunction(iconAttrs)) {
iconProps = {
glyph: iconAttrs,
};
} else if (isObject(iconAttrs)) {
iconProps = pick(iconAttrs, [
'className',
'glyph',
'label',
'primaryColor',
'secondaryColor',
]);
}
return iconProps;
};
So, whenever I pass a function that returns the react node of a custom icon, I see prop-type exeptions in the console. The icon renders fine.
This does not happen on the pull request extension points.
Could the prop-type validation in the extension-point-wrapper.jsx be adapted that also a func is allowed?
Hi!
I also have issues resolving com.atlassian.bitbucket.repository.ref.restriction.RefRestrictionService with @ComponentImport, could you please make this available as bean?
Thanks
Thanks for reporting.
This seems like prop-type validation hasn’t been accurate as it renders the icon correctly but throws console error. I’ll make this change in the next eap.
I wasn’t able to replicate this locally. Can you provide some more details for how you’ve wired up this bean and the stack trace it created?
We’ve made org.apache.http.* packages public since it’s part of platform public API, and because AMPS has banned vendors from bundling this dependency.
org.apache.http packages wasn’t part of removed dependencies.
Confluence have also made these packages publicly accessible in their Confluence 9 beta releases.
Thanks for EAP9.
Web panel classes throw a ClassCastException (Hello Webpanel World, not shown)
2024-07-04 19:39:12,606 WARN [http-nio-7990-exec-4] admin @KFLAF1x1179x117x0 dhbzyb 0:0:0:0:0:0:0:1 "GET /projects/PROJECT_1/repos/rep_1/browse HTTP/1.1" c.a.s.i.w.f.WebFragmentSupport An error occurred rendering com.izymes.test:test-hello-web-panel. Ignoring
java.lang.ClassCastException: class com.izymes.test.web.HelloWebPanel cannot be cast to class com.atlassian.plugin.web.model.WebPanel (com.izymes.test.web.HelloWebPanel is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @219cc895; com.atlassian.plugin.web.model.WebPanel is in unnamed module of loader org.springframework.boot.loader.LaunchedURLClassLoader @6f1fba17)
Static web panels work (“Hello Static World”).
Web panels must now implement com.atlassian.plugin.web.api.model.WebPanel
but something is going pear-shaped at runtime.
Source: web-panel-fail
This is a bug that has been fixed, but I guess hasn’t made its way into the EAPs yet: Bitbucket
Thanks Reece! You’ve got your fingers in a lot of pies, hey!
Looking forward to this fix in the next EAP.
You’d think I work for Atlassian too as a side hustle 
