Hi Kusal,
Can you clarify which endpoint requires this? Are you referring to the UPM endpoint POST /rest/plugins/1.0/?
If so, may I assume you mean that this method now requires another multipart form-data section with name=“pluginSource”, containing a body payload of the string “UPLOAD”?
Scott
Hi @Kusal ,
Thanks so much for your help. I’m happy to report that we were able to get our app building & running successfully in 10.0.0-m21 after changing all of our javax.* dependencies and imports to the jakarta.* equivalents.
(It is unfortunate that we are not able to maintain a single version of our app that works across major versions. This will be the first time in the history of our app - going all the way back to Confluence 5 in 2016 - where we will need to juggle separate app versions for Confluence 8/9 vs Confluence 10, so we’ll need to figure out a versioning strategy and release processes to manage this.)
We also took the opportunity to implement dependencyManagement + confluence-plugins-platform-pom as suggested, and removed most of the explicit version from our dependencies.
(In doing so, we discovered that using dependencyManagement like this has actually been an Atlassian recommendation for many years, which makes us wonder why scaffolding out a new app using atlas-create-confluence-plugin from the SDK doesn’t include this? I’m certain there would be many app vendors like us that aren’t following - or even aware of - this guidance simply because the SDK creates apps that don’t implement it. I’m not sure if you have anything to do with the team that manages the SDK, but this may be something to consider to get new apps started on the right path from the beginning - unless there’s a valid reason not to use dependency management by default?)
Question: Should jakarta.inject be included in confluence-plugins-platform-pom? We found that removing the version for this dependency caused issues, which were solved by adding an explicit version to our dependency management as follows:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>jakarta.inject</groupId>
<artifactId>jakarta.inject-api</artifactId>
<version>2.0.1</version> <-- version needed here
</dependency>
<dependency>
<groupId>com.atlassian.confluence</groupId>
<artifactId>confluence-plugins-platform-pom</artifactId>
<version>${confluence.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>jakarta.inject</groupId>
<artifactId>jakarta.inject-api</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
Just wanted to confirm if that is expected.
I’ve clarified that this is indeed a bug - the additional parameter should not be required when app signing is disabled. It’s been raised with the appropriate team.
There are two POST resources at that endpoint. This change only applies to the one accepting application/vnd.atl.plugins.install.uri+json, not the multipart/ one. In any case, the change will be reverted, as per above.
No worries, glad to hear this.
We don’t know if it is impossible but it will certainly be a complex undertaking. Atlassian does not encourage nor provide any support for cross-major compatibility, as has been our stance for all major product version releases. Internally, we use separate plugin branches for each major product version (with Bitbucket’s cascading merge capability).
It’s a valid point, I’ll raise it with the appropriate team.
Thank you for raising this. That is indeed a bug in our POM and we will will look to rectify this in a later EAP. The workaround you are using at the moment is appropriate.
That’s interesting (and sorry this is getting a bit off topic now, so I’ll try to make this my final comment that isn’t specifically related to the 10.0 EAP).
We just did a quick (non-scientific) check of some big names in the Marketplace, and it seems that cross-major support is a bit of a mixed bag.
It is definitely true that some partners (e.g. draw.io, Gliffy) set their compatibility ranges to cover a single major version.
But others (e.g. AppFire’s Numbered Headings, k15t’s Scroll Viewport) do have compatibility ranges that span two or more major versions.
It seems like a common approach is to align the app’s major version to a host product major version, e.g. draw.io 13.x versions are compatible with Confluence 8, while 14.x versions are for Confluence 9, and you’d logically expect 15.x versions soon for Confluence 10 support.
So that’s probably what we’ll end up going with.
That’s right - to clarify my earlier comment, I simply meant that Atlassian won’t provide any technical support on how-to achieve cross-major compatibility or from any issues that may arise from workarounds required to achieve it.
Some apps may be able to achieve Confluence 9.x/10.x compatibility trivially (for example, one that does not leverage Jakarta APIs whatsoever).
Yes, this approach abides by the semantic versioning scheme where the major version
should be incremented if there is a breaking impact on existing consumers.
Hi Kusal,
I followed your suggestion and added <enableAchoo>false</enableAchoo> to the pom.xml to prevent the incompatible developer plugin from being installed. However, after making this change, I encountered a new issue when trying to click the “Configure” button for my plugin.
Now, I receive the following error, using 10.0.0-m23:
[INFO] [talledLocalContainer] -- url: /confluence/plugins/servlet/upm | userName: admin | referer: http://localhost:1990/confluence/plugins/servlet/upm/manage/paid-via-atlassian | traceId: 8b88ce08ae8e2fcb
[INFO] [talledLocalContainer] 11:07:52,782 WARN [http-nio-1990-exec-10] [struts2.dispatcher.Dispatcher] logConfigurationException Could not find action or result: /confluence/admin/plugins/mockups/configure.action
[INFO] [talledLocalContainer] -- url: /confluence/admin/plugins/mockups/configure.action | userName: admin | referer: http://localhost:1990/confluence/plugins/servlet/upm/manage/paid-via-atlassian | traceId: 6b49b3d046e55c32
[INFO] [talledLocalContainer] There is no Action mapped for namespace [/admin/plugins/mockups] and action name [configure] associated with context path [/confluence]. - [unknown location]
[INFO] [talledLocalContainer] at org.apache.struts2.DefaultActionProxy.prepare(DefaultActionProxy.java:186)
Despite this error, the plugin configuration has not changed and was working in previous versions. Here’s the relevant section from my atlassian-plugin.xml:
<plugin-info>
<description>Balsamiq Wireframes allows you to add UI wireframes to your Confluence pages.</description>
<version>999.999</version>
<vendor name="Balsamiq" url="https://balsamiq.com" />
<param name="atlassian-licensing-enabled">true</param>
<param name="configure.url">/admin/plugins/mockups/configure.action</param>
<param name="post.install.url">/admin/plugins/mockups/configure.action?postInstall=true</param>
<param name="post.update.url">/admin/plugins/mockups/configure.action?postUpdate=true</param>
<param name="atlassian-data-center-status">compatible</param>
</plugin-info>
It seems that Confluence is no longer recognizing the action mapping for /admin/plugins/mockups/configure.action.
Could this issue be related to disabling the AMPS developer plugin? Or is there something else that might be affecting how the configuration page is resolved?
Have you checked that all your plugin modules are enabled as expected in UPM? I suspect you may be using the <xwork> module which has been removed. If so, please use its replacement <struts> instead.
Thank you for your suggestion earlier! After replacing <xwork> with <struts>, the plugin configuration is now working correctly. I was able to add the macro to a Confluence page and create a new wireframe.
However, I am now encountering an issue when the macro gets rendered on the page. The logs show the following error:
[INFO] [talledLocalContainer] 12:04:04,436 ERROR [http-nio-1990-exec-2] [view.macro.ViewMacroMarshaller] handleMacroExecutionException Error rendering macro: wireframe
[INFO] [talledLocalContainer] -- page: 1114113 | referer: http://localhost:1990/confluence/pages/resumedraft.action?draftId=1114113&draftShareId=17b88b26-21ad-4522-97b0-59deaac8c742& | traceId: 0e3bb2974edfdbbf | userName: admin | action: viewpage | url: /confluence/spaces/ds/pages/1114113/test
[INFO] [talledLocalContainer] java.lang.LinkageError: ClassCastException: attempting to cast jar:file:/Users/andreaserra/code/bw-confluence/target/container/tomcat10x/cargo-confluence-home/webapps/confluence/WEB-INF/lib/javax.ws.rs_javax.ws.rs-api-2.1.1.jar!/javax/ws/rs/ext/RuntimeDelegate.class to jar:file:/Users/andreaserra/code/bw-confluence/target/container/tomcat10x/cargo-confluence-home/webapps/confluence/WEB-INF/lib/javax.ws.rs_javax.ws.rs-api-2.1.1.jar!/javax/ws/rs/ext/RuntimeDelegate.class
[INFO] [talledLocalContainer] at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:125)
[INFO] [talledLocalContainer] at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:97)
[INFO] [talledLocalContainer] at javax.ws.rs.core.UriBuilder.newInstance(UriBuilder.java:72)
[INFO] [talledLocalContainer] at javax.ws.rs.core.UriBuilder.fromPath(UriBuilder.java:125)
It seems like there is a java.lang.LinkageError caused by conflicting JAX-RS dependencies (javax.ws.rs-api-2.1.1.jar).
Checked for duplicate dependencies
I ran:
atlas-mvn dependency:tree | grep javax.ws.rs
but found nothing, so there doesn’t seem to be another explicit reference to javax.ws.rs-api in my plugin’s dependencies.
Importing javax.ws.rs.core.UriBuilder
I am importing javax.ws.rs.core.UriBuilder; in my macro class, which might be triggering the JAX-RS dependency issue.
Added Jakarta JAX-RS API Dependency
In pom.xml, I have added the following dependency:
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>jakarta.ws.rs-api</artifactId>
<version>${jakarta.ws.rs-api.version}</version>
<scope>provided</scope>
</dependency>
javax.ws.rs-api, while my plugin now includes jakarta.ws.rs-api?javax.servlet.api) ?<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.1.1</version>
<scope>provided</scope>
</dependency>
Thanks!
Have you tried using the Jakarta variant? Java EE 8 (javax) packages are no longer supported.
Please also configure your dependencyManagement as explained in my earlier post.
Thanks for the advice again, I found the issue:
I had <jakarta.ws.rs-api.version>2.1.6</jakarta.ws.rs-api.version> in my POM due previous eap versions and after setting it to <jakarta.ws.rs-api.version>3.1.0</jakarta.ws.rs-api.version> I was able to import jakarta.ws.rs.core.UriBuilder; !
Now all seems it is working, thanks for the help !
Could be useful to know when to remove the temporary workarounds you suggested, at the moment in the POM I still have:
<dependency>
<!-- Temporary workaround -->
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<scope>provided</scope>
</dependency>
...
<!-- Temporary workaround -->
<enableAchoo>false</enableAchoo>
No worries, good to hear
We’ll provide updates when possible, but you may otherwise assume they are all resolved once the beta is released.
Hello,
we are currently using m23 and are trying to install our app. It fails because of a missing OSGI-import:
missing requirement [299](R 299.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.user.impl)(version>=3.0.0)(version<=3.0.0))]
EDIT: I realized this problem also occurs on Confluence 9.3.2 (not on 9.3.1 though).
I didn’t find any information related to this Patch-Version. My guess is that it’s related to: https://jira.atlassian.com/browse/CONFSERVER-53264?src=confmacro
Can you help us with that?
If it’s unavailable, you can’t use it anymore and should find/implement an alternative.
Unfortunately I’m only able to respond to 10.0 EAP specific feedback going forth.
Can someone help me with the docker image for this?
Hello!
I am in the process of upgrading my Confluence plugin to support Confluence EAP 10, but I’m facing an issue where one of my modules (auth-configure-xwork) is getting disabled.
atlassian-plugin.xml under:
<xwork name="XWork Actions" key="auth-configure-xwork">
com.atlassian.xwork.PermittedMethods has been replaced with com.atlassian.struts.httpmethod.PermittedMethods.xwork module into a Struts-based approach?atlassian-plugin.xml configuration, and if so, how should it be structured?pom.xml for this migration?Here is the properties section of my pom.xml:
Any help or guidance would be greatly appreciated!
Thanks in advance.
You need to change the XML tag to <struts ...> as of Confluence 10, because it seems that they dropped backwards compatibility with the old name.
That’s correct, I’ll have this added to the ‘Preparing for’ notes as it has been missed.
Hi all,
The previously mentioned issues with the confluence-plugins-platform-pom have been rectified with the latest EAP. You may now inherit the correct version for all your provided scope dependencies by importing that POM.
We’ve also removed the old JAX-RS packages from the available OSGi exports. And just to reiterate, none of the Java EE 8 packages (javax) should be used with Confluence 10.0 despite some of them still being OSGi available. We will continue to remove such packages from OSGi availability as we approach the beta.
As always, if you observe any genuine issues with the new jakarta packages in your apps, please report them and we will investigate.
To get the Docker image, please follow this link: [Docker]
Hi,
Trying to run Confluence 10.0.0-m26 over AMPS and getting Container tomcat10x not supported. This is what I have in my pom:
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>confluence-maven-plugin</artifactId>
<version>${amps.version}</version>
</plugin>
....
<amps.version>9.2.6</amps.version>
[INFO] Confluence WAR file contains bundled library metadata
[INFO] Neither Confluence WAR nor AMPS configuration contains com.h2database:h2, adding extra container dependency com.h2database:h2:1.4.200:jar
[INFO] Neither Confluence WAR nor AMPS configuration contains org.hsqldb:hsqldb, adding extra container dependency org.hsqldb:hsqldb:2.3.0:jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 35.729 s
[INFO] Finished at: 2025-03-17T09:47:47+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.atlassian.maven.plugins:confluence-maven-plugin:9.1.4:debug (default-cli) on project scroll-ui-tests: Execution default-cli of goal com.atlassian.maven.plugins:confluence-maven-plugin:9.1.4:debug failed: Container tomcat10x not supported -> [Help 1]
Why is it trying to call 9.1.4 despite the fact that 9.2.6 is specified?
Daria