A Confluence 10.0 EAP milestone is now available. EAP releases provide a snapshot of our work in progress and give you an opportunity to test and fix your apps before the final release.
As usual, we’ll be releasing weekly milestones and betas during the development of Confluence 10.0, so head to Preparing for Confluence 10.0 to find out what’s changed.
If you have any problems with an EAP release, please raise an issue to let us know. The earlier we know about problems, the more time we’ll have to fix them before the final release.
Enjoy!
The Atlassian Confluence team
We now announce Confluence Data Center releases and more in the Atlassian developer changelog. Subscribe to the changelog to receive the latest updates.
Cannot use this EAP. The App Management fails instantly, and we can’t install our app through the REST API because it gets rejected by 500 Unauthorized.
There’s also a mixture of Jakarta 1.x and 2.x versions of the same libs. It would probably make sense to complete the transition to 2.x first.
Where could I lookup the correct platform version for a given Confluence version? Could this information be added to the release note or on the post in the developer community?
It is probably obvious, but it is not obvious to me …
Could you or anyone else experiencing this provide further information such as error logs so we can investigate?
Generally, when developing your plugin you will want to import the com.atlassian.confluence:confluence-plugins-platform-pom to inherit the correct dependency management.
Shouldn’t be automatically included ? It seems the Confluence server package is missing some core dependencies.
Another question: the new Struts 7 dependencies upgrade are breaking the compatibility with Confluence 9.xx and older ? Meaning if we compile our plugin to be compatible with Confluence 10 we are no more able to install it on previous versions ?
About the Bandana Removal can you provide some code example to fetch the old data from the BANDANA storage in order to migrate old data to another method, like AO ?
We’ve identified the issue with UPM which is preventing plugin installs from the web UI and REST API. This will be rectified in the next EAP.
Most dependencies need to be explicitly specified. However, you should inherit the version management by importing com.atlassian.confluence:confluence-plugins-platform-pom. See my dependencyManagement snippet further down.
In general, yes.
There is no new dedicated API for migration, you should use the existing BandanaManager API, which will have its mutative APIs blocked.
This will be rectified in the next EAP.
The JAX-RS and Jersey dependencies are currently pinned to the incorrect versions in confluence-plugins-platform-pom due to some technical hurdles. This will be fixed in a later EAP but you may work around this issue by adding the following additional dependencyManagement entries for now.
2025-03-10 update: The temporary workaround entries below are no longer required!
We are aware of a handful of OSGi services which still leak the old javax.servlet.* APIs. Whilst not ideal, you may workaround this by depending upon both the old and new Servlet APIs. You may also need to specify an optional OSGi import. Please ensure you remove this workaround once these services are corrected in later EAPs.
For EAP2, can you clarify the scope of the Bandana removal? I understood that only mutative options were to be blocked, but I am seeing this error on plugin install.
For example, is the entire com.atlassian.bandana package being intentionally marked for internal use only? If so, what is the suggested alternative for read-only access to migrate old data?
Also, for future EAPs, is there any possibility of Atlassian publishing a changelog of sorts for any changes made to the OSGi export denylist? I understand that we can technically find this out by unzipping the internal Confluence JAR and diffing the public-api and package-exports.yaml files, but it would be nice if this information could be posted publicly so that not everyone has to reinvent the wheel.
I see that some legacy packages (like javax.servlet) are still exported in the OSGi context in -m20.
Are these expected to be fully removed? If so, do you know when?
I am exploring to see if there is any way at all to create a cross-major app. I was hoping to verify if a particular feature of OSGi might work, which is that optional imports will override any locally-defined classes declared within a bundle.
This could allow, for example, apps to declare their own shim version of javax.servlet classes that extend the corresponding jakarta.servlet class, but to also optionally-import javax.servlet from the host context.
On Confluence 9.x, the javax.sevlet classes will be imported directly and the shim layer would not be used. On Confluence 10, it would end up invoking the parent jakarta classes through the shim.
The problem is that for this to work, javax.servlet cannot be exported in Confluence 10, hence my question about its removal.
Thanks for raising this - this was indeed an oversight and we will restore these packages to public API in the next EAP.
We don’t intend to make any major changes to publicly exported packages from here on, other than the removal of Java EE 8 packages. If you are already going down the path of extracting the Confluence JAR, I’d recommend consulting com/atlassian/confluence/impl/util/OsgiAcceptanceTest-expected-public-api-exports.txt instead, which resolves the mentioned YAML files against packages actually on the classpath.
What is the use-case for retrieving them?
Yes, but towards the end of the development cycle. There are still a number of public APIs which leak/depend on the legacy packages and removing these prematurely could render some marketplace apps uninstallable.
Whilst this is not an approach we recommend due to the complexity and tech debt introduced, you may find this Atlassian library helpful in your experimentation.
@Kusal we can have our forms (ConfiForms) configuration grouped as a user macro and need to read the template → macro configuration. Helps our users to group and reuse form configurations
Just tried building one of our apps using 10.0.0-m20 (which I’m assuming is the latest EAP build).
(Builds fine against 9.3.1).
Got the following error (I added line breaks for readability):
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 07:14 min
[INFO] Finished at: 2025-02-19T12:57:54+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.atlassian.maven.plugins:confluence-maven-plugin:9.1.11:run (default-cli) on project [REDACTED]:
Unable to find/resolve artifact.:
Failed to read artifact descriptor for com.atlassian.synchrony:synchrony-proxy:war:5.0.0-CONFSRVDEV-34351-m02:
The following artifacts could not be resolved:
com.atlassian.confluence:confluence-plugins-platform-pom:pom:9.3.0-CONFSRVDEV-34351-m01 (absent):
Could not find artifact com.atlassian.confluence:confluence-plugins-platform-pom:pom:9.3.0-CONFSRVDEV-34351-m01 in atlassian-public
(https://maven.atlassian.com/repository/public) -> [Help 1]
Is this a known issue?
I’m using AMPS 9.1.11 if that makes any difference.
We usually wait until later in the EAP cycle before testing, but we wanted to get a head start this time around, and possibly we should wait a bit longer?