Confluence 10.0 release EAP is available now

[anastoumi]

Hi @Kusal
I’m trying to make the changes on the plugin, so it can run on actual confluence beta. But i have a problem when replacing javax with jakarta.
First, i changed the imports.

Then, i replaced the depedency from javax to jakarta, and tried the scopes : compile, or provided, and versions : 5.0.0 then 6.0.0 then 6.1.0

And before last step, i updated the properties versions in pom.xml

But when Compiling i always have the error of not finding the dependency in Atlassian repo

And had this message too :

Failed to execute goal on project app1: Could not resolve dependencies for project com.company1.confluence.plugins:app1:atlassian-plugin:3.0.0.3: Failure to find jakata.servlet:jakata.servlet-api:jar:5.0.0 in https://maven.atlassian.com/repository/public was cached in the local repository, resolution will not be reattempted until the update interval of atlassian-public has elapsed or updates are forced

Any ideas about this problem ?

[EliasBrattliSorensen]

@anastoumi Typo. Jakata → jakarta

[jens]

There’s a typo in your groupId and artifactId.
It says jakata but should be jakarta. And you probably want version 6.

<dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>6.0.0</version>
    <scope>provided</scope>
</dependency>

[anastoumi]

@EliasBrattliSorensen @jens many thanks to you guys, yesterday after fixing the typo, and put back to version 6.0.0, all became in order. probably I need to change my glasses, as soon as possible

[Courage]

@Kusal why is this directive: !javax.annotation, and !javax.annotation.*, not respected, even when it is specified in the <Import-Package> directive of the POM? It is overridden when the plugin is installed. The only version where the directive respected is in 10.0.0-m73. Any ideas why this is happening ?

[richard.white]

We had this issue as well - we note is seems to occur due to us using the old style component imports in the atlassian-plugin.xml, which results in a “transformed” plugin, where the manifest is rewritten by Confluence when the plugin is uploaded, to also include imports required for all of your component imports.

We noticed some components from the cache api and beehive are still using javax.annotation e.g. CacheManager and ClusterLockService.

Would be good to get guidance from Atlassian whether this will be fixed in a future EAP or we finally have to bite the bullet and convert to a transformerless plugin (ie. Spring scanner 2 etc.)

[AndreasEbert]

I and many other vendors already bit the bullet with Confluence 9. I’m curious how you managed to make the old way work so long for your app.

[Kusal]

@richard.white

seems to occur due to us using the old style component imports in the atlassian-plugin.xml, which results in a “transformed” plugin

Thank you for confirming this @richard.white - I’d admittedly overlooked the possibility of the plugin being transformed in my previous replies, but this definitely explains the issue.

@richard.white

Would be good to get guidance from Atlassian whether this will be fixed in a future EAP or we finally have to bite the bullet and convert to a transformerless plugin

Unfortunately we are unable to rectify this and other limitations of transformed plugins. If your plugin is impacted by this issue, you will need to convert your plugin to transformerless. Transformed plugins should be considered deprecated and support for them will be removed in a future release.

Our recommended approach to implementing a transformerless plugin is using Spring Java configuration, however the use of Atlassian Spring Scanner, or Spring XML files are also perfectly acceptable. The <component> and <component-import> plugin modules are NOT supported by transformerless plugins.

The most critical step for conversion is specifying an <Atlassian-Plugin-Key> in your <instructions> - this signifies that your plugin should not be transformed.

[scott.dudley]

Removal of hover-related resources

As part of our continued effort to enhance accessibility in Atlassian products, we’re removing the following resources:

AMD modules

• confluence/hover-user

For confluence/hover-user, although it was removed, I discovered that equivalent functionality seems now available through the AMD module confluence/user-dialog. Perhaps the docs should be updated?

[richard.white]

We found a way to debug which components were causing bad imports and until now found it easier to replace them than to convert to tranformerless. We do have unusual situation of a single codebase for a Jira, Confluence, Bitbucket, Bamboo and Fecru app, which makes the conversion a little more time consuming for us.

[richard.white]

OK. Yes, understood, we have had to do it in the past for some of our simpler plugins. I do find it a little frustrating that Atlassian can’t commit to removing these imports of deprecated packages from supported platform components, since they are requiring all vendors to do it for all of our code.

[Courage]

@Kusal
I am having trouble with the @ComponentImport annotation in the Confluence 10.0.0. The same configurations works in 9.x.x

We have everything setup correctly as per this Atlassian Spring Scanner Bitbucket guide.

However, none of Atlassian’s Component is being injected at runtime.

Any idea why this is happening ?

[Kusal]

@scott.dudley

I discovered that equivalent functionality seems now available through the AMD module confluence/user-dialog. Perhaps the docs should be updated?

Thanks for the feedback - I’ve forwarded this note to the responsible team.

---

@Courage

Any idea why this is happening ?

There’s not enough information to tell.

---

We’ve merged a tweak to the plugin transformation process which should prevent javax.annotation being added as a mandatory import. This change will be available in 10.0.0-beta3.

Note that transformed plugins should still be considered deprecated and support for them will be removed in a future release.

[Anja]

Hi @Kusal,
concerning the contentPropertyManager, you stated

From Confluence 9.4 onwards, ContentPropertyManager is no longer backed by the PropertySet library but continues to use the same database table - we now interact with it directly and have unified the String and Text types for simplicity. We will remove ConfluencePropertySetManager alongside the PropertySet library in 11.0, but String/Text properties will remain accessible via ContentPropertyManager. No data migration will be required.

When you say ‘no data migration will be required’, does this mean that if we used setTextProperty/getTextProperty until now for Confluence 8/9, in Confluence 10 we can just use setStringProperty/getStringProperty - and what was previously saved as Text can be retrieved with getStringProperty. So no migration or other action is required from our side to make this part in our code compatible, correct?

Cheers,
Anja

[Kusal]

@Anja

and what was previously saved as Text can be retrieved with getStringProperty. So no migration or other action is required from our side to make this part in our code compatible, correct?

That’s correct

[fgrund]

Regarding the suggestion to add a #getKeys API - this is a sensible addition, but unfortunately it’s too late to commit to this for 10.0. I’ve added it to our backlog to implement prior to 11.0.

So would we need to find a workaround in Confluence 10 where we store all our keys as separate items in Bandana? This seems like a very fragile approach for me. Please help us with any other ideas for workarounds. getKeys was a core piece of our app with Bandana.

Edit: I just realize we might be able to keep using Bandana’s getKeys in Confluence 10

[Kusal]

@fgrund

So would we need to find a workaround in Confluence 10 where we store all our keys as separate items in Bandana?

The message you’re responding to has no relation to Bandana - it refers to the PropertySet APIs.

@fgrund

getKeys was a core piece of our app with Bandana.

com.atlassian.bandana.BandanaManager#getKeys will not be removed until Confluence 11.0. We’ve also already introduced a replacement API: com.atlassian.confluence.api.service.settings.ExtendedPluginSettings#getKeys.

[Kusal]

Please note that opensymphony:propertyset has been removed as a transitive of the primary confluence artifact from 10.0.0-beta3. If you still depend on those deprecated APIs, please specify that dependency explicitly (in provided scope as it should still be OSGi imported).

[SBobadilla]

Hello,
I’m trying to upload a plugin that I’m a developer of to test the compatibility with the new beta3 version, but getting the “Signature check failed” error. I thought that this was disabled by default in the dev builds (I use atlas-run-standalone from the sdk). Is there a way to override this or how can I get my plugin to install correctly without the signature part?

[PumpeCedric]

@Kusal

official recommendation is to publish separate major versions of your plugin for each major product version

Hey @Kusal
that’s a fair point! However, it would be really nice if the Atlassian marketplace would display version compatibility accordingly. Visiting a plugin in the marketplace it only shows the version compatibility for the latest DC release.
So if one releases an update first for Confluence 9, and a few minutes later for Confluence 10, it will only show compability with Confluence 10.
It would be awesome, if it would show compatability from 9-10 in that case.
Is something like this planned?