Platform 7 upgrade in progress: Learn about the first highlights and changes

Hi @clouless

I was able to fix the issues you faced around REST v2. I released:

  • REST v2 7.2.6 → Platform 6.5.6
  • REST v2 8.0.0-m04 → Platform 7.0.0-m19

You may need to wait couple more days for Confluence team picking up the changes and adopting them.

In the meantime you could use “RefApp” (the same versioning as Platform) to play with the new API. If you need Confluence for your plugin, you can try override the version of REST v2 by using pluginArtifacts mechanism in AMPS. I cannot guarantee it will work properly though.


Hi @mkemp
Thanks a lot :slight_smile: I will wait and report back here if everything works now :slight_smile:

1 Like

Hi @MarekTokarski

thank you for sharing the lists.

I remember that you are still working on the final list, but I have a small question about one artifact. Do I understand correctly that platform-public-api contains/should contain all available artifacts that the platform provides (scope = provided) and all others should be added to the application (scope = compile)?

For example:


The above artifact is not on the list available on platform 7 (platform-public-api v. 7.0.0-m20) but it is available and can be added as scope = provided (I found it in the Confluence source)…
should this artifact be on the platform-public-api list, or will it be removed and no longer available?


Hi @MarekTokarski

How is the progress on updating the dependencies in platform-public-api?

I recently noticed that a POM version 7.0.0-m20 has been released, but unfortunately it does not contain any significant changes compared to version 7.0.0-m15 (see attached screenshot comparing the two POM files).

Could you please provide an update on the status of this work?

Diff 7.0.0-m15 vs 7.0.0-m20


Hi @adam.labus

Platform public API defines the minimum set of dependencies that you can expect from products. If you are using dependency defined there, it should have scope provided. Products can add more libraries to the public API, so you shouldn’t use compile only because it is not defined in Platform.

I asked Confluence team and they don’t plan to support slf4j-simple. If it is publicly available, it will most probably disappear. Can you elaborate why do you need access to that library? In general we are recommending SLF4J API and in most cases dependency on that library should be enough for plugins.

Hi @rafal.janiczak1

I will be honest with you. It is on my short list of tasks :slight_smile:

Please note that we have more POMs than platform-public-api that are used internally by the DC teams. The recent milestones were focused mostly around REST v2.

1 Like

Hi @MarekTokarski

thanks for the explanation and information! :slight_smile:

I needed something to replace log4j, but slf4j-api works the same as sl4j-simple, thanks.

1 Like

If you want to simply log your messages, then slf4j-api is definitely something you should use.

slf4j-simple is actually an SLF4J “provider”. It simply redirects all the logs to System.err. It can be useful to add dependency to slf4j-simple in test scope. Otherwise you may encounter an error like:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See for further details.

You don’t need to care about the providers when running integration tests or in production. SLF4J provider is an implementation detail (depends on what logging framework is used in the product). If you rely on slf4j-api you can be sure all your messages will be logged.


Hi @MarekTokarski

Regarding REST v2, I was hoping you could provide guidance on how to migrate a ServiceExceptionMapper to REST v2. We implemented a RestExceptionMapper because Atlassian says that we should use one to implement Confluence Read-Only mode.

The ServiceExceptionMapper class is defined in the com.atlassian.confluence:confluence-rest-api artifact.

When I tried to migrate to REST v2, I added to the POM as instructed and built without removing the old confluence-rest-api package.

The build succeeds (with both modules as scope=provided), but the app fails on install to Confluence 9.0.0-m13 with the error below:

Caused by: org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve resource myapp [myapp [301](R 301.0)] because it is exposed to package '' from resources [ [163](R 163.0)] and org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two dependency chains.

Chain 1:
  myapp [myapp [301](R 301.0)]
    import: (
    export: osgi.wiring.package: [ [163](R 163.0)]

Chain 2:
  myapp [myapp [301](R 301.0)]
    import: (
    export:; [ [162](R 162.0)]
    import: (&(>=1.1.1))
    export: osgi.wiring.package:

But if I remove confluence-rest-api from the POM, it won’t even compile because the ServiceExceptionMapper class is gone.

Your insight would be appreciated.

Hi @scott.dudley

You are facing an issue of dependency chains in an environment that is not fully migrated. We introduced REST v2 early, to give opportunity to acknowledge the changes, but situations like that may happen before the final version of the product.

Your specific case is caused by the fact that Confluence didn’t fully migrated internally. Confluence has its own API on top of REST (confluence-rest-api) that need to be updated. I assume it will happen in one of the following Confluence EAPs.

I will redirect this call to the Confluence team. It will be definitely fixed in the final version.

I’m not fully aware how “read only” mode works in Confluence, but as a temporary workaround you could decide to ignore this requirement or implement an that ServiceExceptionMapper implements. Of course it wouldn’t be a production ready solution, rather a temporary solution to allow playing with REST v2 and checking compatibility.


Hi @MarekTokarski

That’s a great idea. It looks like it is still not ready for prime time though, since Confluence 9.0.0-m13 is also not exporting the package to third-party plugins (needed for @AnonymousAllowed and so on).

It is exporting .api.model, .api.annotation and plenty of others though, so I imagine this is an oversight?


1 Like

I will redirect this request to the Confluence team. It is definitely a misconfiguration. Anything from* should be public, except for*.

From slightly different reasons I updated REST exports. Starting from REST 8.0.0-m08 product’s configuration doesn’t have effect on the public/internal exports - even if they misconfigured, everything should be still visible at runtime. We still need to release updated Platform and wait for the adoption in Confluence.


As far as I understand, Jira will support restV2 from the 9.15 version. You said Rest v1 will be removed from the product at some point. Let’s say that the mentioned point is Jira 10.0. Does it mean that we won’t be able to support Jira versions lower than 9.15 and 10.0 and higher with single plugin version/build?

I would greatly appreciate if you could publish an example plugin source code that includes a working REST v2 configuration in pom.xml and atlassian-plugin.xml, maybe with multiple branches for platform 6, 6.5, 7 so we can easily experiment and compare with our projects.

I found that refapp-plugins/charlie-plugin has a rest-v2 config on the 6.5.x branch but the rest endpoints are disabled when installing the plugin on Confluence 8.8.0/8.8.1
Would be great to see a working config example

Hi @MarcinHarezaAppfire

Yes, if your plugin is using REST then you will have to have separate versions for product versions with REST v1 and REST v2. Please have in mind, that there are more breaking changes coming in Platform 7 that may have the same effect on your plugin.

Hi @KsaweryBuczkowski

That is a very good call! It happens I have a solution for you already :smiley:

We have a set of samples that we are using internally to validate the features. They should cover most capabilities included in REST v2:


Hi @KsaweryBuczkowski

Please have in mind that “Charlie Plugin” is meant for RefApp. It doesn’t contain any specific product code at the moment, but we cannot guarantee it is working with the products.

The issue you are facing is caused by the fact that we already migrated “Charile Plugin” to REST v2. From what I know Confluence 8.8 migrated to Platform 6.5, but they didn’t include the new plugin - REST v2. That specific capability will be present in Confluence 8.9, based on my knowledge.

There are, but so far, all can be overcome by reflection.
Isn’t it a better idea to remove v1 support from Jira when the last version without v2 support will stop being supported by Atlassian?

Hi @MarekTokarski

thank you, it will definitely come in handy :slight_smile:

Sorry, I can’t find any additional description anywhere, but… is there any information available about what we, as developers/partners, gain by moving from REST v1 to REST v2 - are there any pre-release notes, new functionalities?