Noting that in the next EAP, a selection of classes from the following packages have been extracted to the new artifact com.atlassian.confluence:confluence-struts
com.atlassian.confluence.impl.strutscom.atlassian.confluence.plugin.strutscom.atlassian.confluence.setup.strutsQuick update on the migration to PluginSettings (due to Bandana deprecation):
Indeed, we in our app had to handle manually only a Map<String, Object> value; all other values (String, Integer, Long, Boolean) were migrated automatically by CF10. Looks good 
A small side-effect we noticed:
For apps’s Scheduled Jobs the run-history is wiped. I think because they are stored as List<Object> in Bandana, which are not auto-migrated (only List<String> is auto-migrated). Not a big deal, but wanted to mention it anyway.
Thanks for the feedback - good to hear!
This shouldn’t be the case, unless you are attempting to retrieve this data via PluginSettings directly rather than via the schedule job manager/service APIs.
But yes, this particular data has not been automatically migrated to the new PLUGIN_SETTING table for the reason you’ve stated. There are still a handful of internal Confluence classes that are still writing/reading from the old BANDANA table and we are still in the process of manually migrating these usages (and their associated data).
The class (com.atlassian.plugin.osgi.external.ListableModuleDescriptorFactory) was provided by atlassian-plugins-osgi:
[INFO] + com.atlassian.confluence:confluence:jar:8.5.0:provided
[INFO] | + com.atlassian.plugins:atlassian-plugins-osgi:jar:7.2.0:provided
It is not provided anymore because you recommend to rely on confluence-plugins-platform-pom. The Atlassian Spring Scanner 6.0.0 doesn’t work for us (as reported in this question) because it doesn’t reliably return components from other plugins. Example:
Plugin 1
package com.plugin1;
@Component @ExportAsService(com.plugin2.MyInterface)
public class MyComponent1 implements com.plugin2.MyInterface {...
Plugin 2
package com.plugin2;
public interface MyInterface { ... }
// This command won't work reliably
list = pluginAccessor.getEnabledModulesByClass(com.plugin2.MyInterface.class);
// 'list' doesn't contain MyComponent1
If you can give me any implementation which can retrieve components from other plugins that implement our interface, I would be able to drop our dependency on atlassian-plugins-osgi.
And it’s still provided by that artifact and should still be used when defining a ModuleDescriptorFactory using Atlassian Spring Scanner.
I think it’s possible you’ve misunderstood the purpose of the confluence-plugins-platform-pom. It is a BOM which specifies version management for dependencies applicable to Confluence plugin development, It ensures you are compiling against the correct dependency versions for the version of Confluence you are targeting. You must still specify the artifacts which your plugin depends on explicitly - you should simply leave out the version declaration.
You must use version 6.0.0 for guaranteed compatibility with Confluence 10 (DC Platform 8, Jakarta EE 10).
Having had a brief look at your other thread it’s possible there’s another factor at play. The PluginAccessor and the mentioned method are used in Atlassian plugins and we’ve not observed any issues. Given you believe this bug was introduced in Confluence 8.9 (rather than 10.0), I recommend pursuing this with Atlassian developer support who will be able to assist with an initial investigation and escalate to the appropriate developer team if necessary.
You may also choose to experiment with converting your plugin to Spring Java config, although PluginAccessor behaviour should not be impacted by this.
We’ve not asked plugin developers to drop this dependency. The packages in this artifact which were previously OSGi exported will remain so.
Both of these issues should be fixed in AMPS 9.3.6.
We upgraded our app from version m58 to m85 and we are experiencing that our app is disabled. It tells us that this dependency is missing:
osgi.wiring.package=javax.annotation
Due to the jakarta update we have switched from javax dependencies to jakarta. So we don’t have any direct reference to javax.annotation anymore.
Do we still need this dependency?
As far as we know it is no longer provided from Atlassian side.
My AMPS version is 3.6.3
Thanks.
After upgrading our app to m85, our pluginDependencies don’t get installed anymore.
This is the start command we use to install the main App and the pluginDependency:
atlas-mvn confluence:debug -DskipTests -pl atlassian-apps/MainApp -Dplugins=PluginDependency:version
We defined the PluginDependency like this:
<plugin>
...
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>confluence-maven-plugin</artifactId>
<configuration>
<pluginDependencies>
<pluginDependency>
<groupId>...</groupId>
<artifactId>...</artifactId>
</pluginDependency>
</pluginDependencies>
...
</plugin>
Even if we package the app manually when Confluence is already running, the PluginDependency doesn’t get installed.
One thing we could think of was an issue with the app signing, so we tried to add this SystemPropertyVariables:
<atlassian.upm.signature.check.upload.disabled>true></atlassian.upm.signature.check.upload.disabled>
<atlassian.upm.signature.check.disabled>true</atlassian.upm.signature.check.disabled>
What can we do to resolve this issue?
Thank you
You should switch to jakarta.annotation. If your plugin’s OSGi import instructions still contain javax.annotation due to a leak, you can explicitly exclude it by adding !javax.annotation.*, to your import instructions.
Please check the Confluence application logs.
Hi @Kusal ,
Thank you for your help! We have switched to jakarta.annotation and have also tried to directly exclude it with !javax.annotation.*, but we still had the same error. So this didn’t helped.
Hello 
Previous Confluence versions (9.x) provided jakarta.mail.
Using 10.0.0-m105 the jakarta.mail dependency is not available anymore, though it was available in earlier milestone versions.
Is this intended and am I supposed to add the dependency in compile scope?
Thank you!