Hi, yes I am doing exactly that:
and that
And I am running the Confluence 10.0.0-m28 docker image and using “atlas-package” and uploading the app.jar => I get this error. And cannot see why
Ok I tried <scope>compile</scope> but it did not change a thing. Also the 0.6.1 is not available via maven.
If that artifact is bundled with your plugin, then when you compile/package your plugin JAR, it will not add import instructions for com.atlassian.plugins.osgi.javaconfig. Perhaps also try uninstalling the plugin manually before installing the newly compiled version.
Thanks for reporting that. It seems to be an error in the documentation - 0.6.0 is the latest version.
Hi Kusal,
Thanks for the input. I completely destroyed the Confluence 10 installation and started from scratch. Did atlas-clean and atlas-package. The OSGI Error seems to be gone, but now I get this error LinaKuhn reported as well. I could solve the javax.ws. errors with new package names.
Here a summary of my REST API Changes for other Partners:
Update Jakarta ws-rs dep to 3.x for new package names:
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>jakarta.ws.rs-api</artifactId>
<version>3.0.0</version><!-- SINCE CONFLUENCE 10 - new package names -->
<scope>provided</scope>
</dependency>
Solve error on javax.ws.rs:
Unresolved requirements: [[foo.app [284](R 284.0)] osgi.wiring.package; (osgi.wiring.package=javax.ws.rs)]
Change all occurrences of:
import javax.ws.rs.Consumes; // ⚠️ => jakarta.ws.rs.Consumes
import javax.ws.rs.GET; // ⚠️ => jakarta.ws.rs.GET;
import javax.ws.rs.POST; // ⚠️ => jakarta.ws.rs.POST;
...
Solve error on (osgi.wiring.package=javax.xml.bind.annotation)]
import javax.xml.bind.annotation.XmlElement; // ⚠️ => jakarta.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement; // ⚠️ => jakarta.xml.bind.annotation.XmlRootElement;
Now the app starts up and the REST Endpoints are working 
Great!
Just FYI you shouldn’t need to do this - confluence-plugins-platform-pom (latest 10.0 milestone) provides the correct version unless you have some other dependencyManagement entries overriding it.
I’d appreciate this. Thanks for taking this with you; I’ll be waiting on your feedback.
I’ve just recalled there may be another option here.
Could you try wrapping your call to PersonService in com.atlassian.confluence.security.PermissionManager#withExemption?
edit: I’ve also just noticed this wrapping method doesn’t pass through the return value - I will have to get back to you once more!
I have just tested the m31 docker image, and I can no longer upload apps (development).
How can I disable the app signing thing?
Also the built app now pulls a lot of stuff in the Manifest and I do not know which of the third party libs pulls that stuff in. I upgraded all third party libs, to latest.
Here is an excerpt of the strange Imports:
java.beans,
java.io,
java.lang,
java.lang.annotation,
java.lang.invoke,
java.lang.management,
java.lang.ref,
java.lang.reflect,
java.math,
java.net,
java.nio,
java.nio.channels,
java.nio.charset,
java.nio.file,
java.nio.file.attribute,
java.nio.file.spi,
java.security,
java.security.cert,
java.sql,
java.text,
java.time,
java.time.chrono,
java.time.format,
java.time.temporal,
java.util,
java.util.concurrent,
java.util.concurrent.atomic,
java.util.concurrent.locks,
java.util.function,
java.util.logging,
java.util.regex,
java.util.stream,
java.util.zip,
javax.annotation,
javax.crypto,
javax.crypto.spec,
javax.lang.model.element,
javax.naming,
javax.net,
javax.net.ssl,
javax.security.auth.x500,
javax.xml.parsers,
javax.xml.transform,
javax.xml.transform.dom,
javax.xml.transform.stream,
javax.xml.xpath,
...
Is there a recommendation what to do? Should I manually mark them as optional? Currently my app does not start and gets a timeout. No osgi error, no other log. Simply does not enable within timeout. Is there an env var to increase the app startup time?
thanks a lot.
My compile scope dependencies
[INFO] +- com.google.code.gson:gson:jar:2.12.1:compile
[INFO] +- org.apache.commons:commons-configuration2:jar:2.11.0:compile
[INFO] +- com.atlassian.plugins:atlassian-plugins-osgi-javaconfig:jar:0.6.0:compile
[INFO] +- org.apache.logging.log4j:log4j-api:jar:2.24.3:compile
[INFO] +- org.slf4j:slf4j-api:jar:2.0.17:compile
[INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.24.3:compile
[INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.24.3:compile
[INFO] +- commons-io:commons-io:jar:2.18.0:compile
[INFO] +- org.apache.commons:commons-lang3:jar:3.17.0:compile
[INFO] +- org.apache.httpcomponents.client5:httpclient5:jar:5.4.3:compile
[INFO] +- org.apache.httpcomponents.core5:httpcore5:jar:5.3.3:compile
[INFO] +- org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3.3:compile
[INFO] +- commons-codec:commons-codec:jar:1.18.0:compile
[INFO] +- commons-logging:commons-logging:jar:1.3.5:compile
UPM App signing disable not working.
I tried to add this to the entry point of the docker image, but I still get the error. How can I achieve “uploaded jars do not have to be signed”?
UPDATE: 
I could disable upm signing with this settings in my entry point:
#
# DISABLE APP SIGNING FOR UPLOADS https://confluence.atlassian.com/upm/configuring-upm-app-signature-check-1489470544.html
#
mkdir /var/atlassian/application-data/confluence/upmconfig
mkdir /var/atlassian/application-data/confluence/upmconfig/truststore
echo "atlassian.upm.signature.check.upload.disabled=true" > /var/atlassian/application-data/confluence/upmconfig/upm.properties
echo "atlassian.upm.signature.check.disabled=true" >> /var/atlassian/application-data/confluence/upmconfig/upm.properties
I also had to pass -Datlassian.upm.configuration.directory=/var/atlassian/application-data/confluence/upmconfig to the docker container, and then it worked.
UPDATE 2: I am no longer seeing specific errors in the logs. The app simply does not enable. Even though setting -Datlassian.plugins.enable.wait=300 the errors do not change and the app does not enable
2025-04-12 07:19:52,338 WARN [UpmAsynchronousTaskManager:thread-2] [osgi.hook.dmz.DmzResolverHook] filterMatches Package javax.servlet is deprecated and is not available for export to plugin myapp
2025-04-12 07:19:52,347 WARN [UpmAsynchronousTaskManager:thread-2] [osgi.hook.dmz.DmzResolverHook] filterMatches Package jdk.net is internal and is not available for export to plugin myapp
2025-04-12 07:19:52,408 WARN [UpmAsynchronousTaskManager:thread-2] [osgi.hook.dmz.DmzResolverHook] filterMatches Package javax.transaction.xa is internal and is not available for export to plugin myapp
2025-04-12 07:19:52,409 WARN [UpmAsynchronousTaskManager:thread-2] [osgi.hook.dmz.DmzResolverHook] filterMatches Package javax.transaction.xa is internal and is not available for export to plugin myapp
2025-04-12 07:19:57,680 WARN [UpmAsynchronousTaskManager:thread-2] [atlassian.plugin.manager.PluginEnabler] isFinished Plugin 'myapp' did not enable within 5 seconds. The plugin should not take this long to enable. Will only attempt to load plugin for another '25' seconds.
2025-04-12 07:20:22,777 ERROR [UpmAsynchronousTaskManager:thread-2] [atlassian.plugin.manager.PluginEnabler] actualEnable Unable to start the following plugins due to timeout while waiting for plugin to enable: myapp
I have already set this in my OSGI Imports in the pom.xml:
<Import-Package>
javax.servlet;resolution:=optional,
jdk.net;resolution:=optional,
javax.transaction.xa:=optional,
I’ve added a new PermissionManager#withExemption method which passes through the return value. Please try this when next week’s EAP is released and see if it is suitable.
I’ll have to get back to you on this. In the meantime you can use the latest AMPS (9.3.2) for development.
I haven’t seen this before and cannot reproduce it. Those are JDK packages and should not be in your import instructions.
In the “Removal of Bandana” section: “The following Bandana value types will be automatically copied to PluginSettingsFactory where possible and under the character limit: (…)”.
Could you add details? I guess: the entry keys remain the same, and the bandana context key becomes the plugin settings key?
Can we definitely rely on that or is it recommended to write a simple plugin upgrade task for the migration?
Good question @cheinig, I wonder if we migrate this data ourselves, will the automated task overwrite it? - I hope not, because that would completely destroy our plugins settings and their internal PluginSettingsFactory mechanism for handling limits 
I’d say it would be quite confusing if all bandana keys are not copied automatically, because if you have values of types other than String, etc., you’d be forced to upgrade them anyway in your custom upgrade process.
That is correct.
If all your Bandana data abides by the supported types and limits, you can rely on this migration and no further upgrade task is required.
This scenario should not be possible. In Confluence 9.x, BandanaManager and PluginSettingsFactory are backed by the same table. In Confluence 10.0, a new table will be introduced and all compatible data copied across during upgrade (after which the old table will become read-only).
If you’ve defined a plugin upgrade task for execution in 9.x which migrates unsupported data types to supported ones - then this migrated data is still written back to the Bandana table, and thus will be retained during the new table migration in 10.0.
Alternatively, if you have defined a plugin upgrade task for execution in 10.0, it will run after the new table creation/migration. This should also not be an issue as your upgrade task will simply overwrite the data from the default migration.
In summary:
BandanaManager code usages to PluginSettingsFactory.BandanaManager code usages to the destination data store(s) you have chosen in your upgrade task.Please note that the new PluginSettingsFactory table is not yet present in the EAPs. You may follow the EAP changelog for when it is available, after which you will able to do further testing.
@Kusal thanks for the detailed explanation!
It looks like our 9.X migration changes will be handled correctly in 10.X.
Of course we are eagerly awaiting the opportunity to test it - I will be following the 10.x changlog.
The Servlet API 4.0 leaks have been rectified in the latest (today’s) EAP and the javax.servlet-api artifact should no longer be required for plugin compilation. The javax.servlet packages have additionally been removed from OSGi availability.
Could you check if this is still the case in the latest (today’s) EAP?
I have removed the javax.servlet-api and tested with the latest EAP m38 + AMPS 9.3.2 and all is working on my part, thank you !
What about the other temporary workaround I have added, is it still needed ?
<configuration>
<!-- Temporary workaround -->
<enableAchoo>false</enableAchoo>
...
I am getting these NoClassDefFoundError: com/atlassian/security/serialblocklist/BlocklistConfigurator errors with m38
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NoClassDefFoundError: com/atlassian/security/serialblocklist/BlocklistConfigurator
java.lang.NoClassDefFoundError: Could not initialize class com.atlassian.security.serialblocklist.velocity.BlocklistUberspector$BlocklistPredicateHolder
I am using this allowlist API for external HTTP calls.
<dependency>
<groupId>com.atlassian.plugins</groupId>
<artifactId>atlassian-whitelist-api-plugin</artifactId>
<version>4.0.7</version>
<scope>provided</scope>
</dependency>
I am not using this class anywhere in my code. I am only using this:
import com.atlassian.plugins.whitelist.OutboundWhitelist
outboundWhitelist.isAllowed(uri.toURI())
And now my unit tests throw this exception.
I believe it should be fixed with the latest AMPS (9.3.2). Are you able to test and report back?
edit: It does not yet seem to be fixed - following up.
I’ll need the full stack trace to investigate further. Although I suspect it can be fixed with:
<dependency>
<groupId>com.atlassian.security.serialblocklist</groupId>
<artifactId>serialblocklist</artifactId>
<scope>test</scope>
</dependency>
Yes, I confirm now it is fixed, thank you
Awesome 
Thanks, now it compiles and tests run through.
UPDATE 
Enabling the app still does not work with m38. Same message timeout and no stack trace anywhere in the logs. (See logs above post)
<confluence.version>10.0.0-m38</confluence.version>
<confluence.data.version>10.0.0-m38</confluence.data.version>
<amps.version>9.3.2</amps.version>
I can confirm that this works for me in 10.0.0-m38 
Thanks for providing this so quickly. Much appreciated.
(Similar to @clouless, I also had to disable the newly introduced App Signature Check first before being able to upload locally build app JARs again. Took me some time, especially because the Linux steps provided in the docu do not apply to my Windows 11 setup.)