Download the beta from our site to start testing your app for compatibility with the changes. Be sure to take a look at our Preparing for Confluence 8.7 guide to find out what you need to do to make your app compatible. We’ll update that page regularly, so keep an eye on it to see any changes.
I see a number of changes in the Confluence 8.7 beta that are not enumerated in the “Preparing for” page:
When installing third-party apps, the system now logs a number of warnings about deprecated OSGi imports. See the thread I posted earlier this week. Can we get an official reaction from the dev team so we can understand what is going on? For example, when are these being removed? Is there an official list, or do we trust the list buried in the code that is shipping?
When attempting to build against 8.7.0-beta1, a significant number of transitive dependencies were removed from the main com.atlassian.confluence:confluence package in Maven (compared to 8.6.0), which cause new errors when trying to build against those dependencies. Why were these removed? Many of these packages are still exported are they are not part of the deprecation list in #1 above. Apps can still manually include the dependency for these components in their own POMs (and then the app works successfully), but this change is unhelpful. Is there another dependency we can include in order to import the full list of whatever is available? Manually declaring the dependencies is suboptimal, because vendors now have to manually sync the component versions every time Confluence itself is upgraded, in order to ensure that our code still builds against the API. This process used to be automatic by just changing the Confluence version number, so this is a downgrade that introduces additional complexity.
For #2, the dependencies that were removed include: atlassian-mail, atlassian-plugins-webresource-common, atlassian-util-concurrent, xstream, and presumably many others.
Adding the explicit dependencies is something everyone will need to tackle, although from 8.7 and prior to 9.0 there’s no need to specify the version. Please see Get your apps ready for Gray API removal and Removal of Gray APIs for discussion of this.
Is the gray API removal only affecting com.atlassian.confluence:confluence?
There are a few of the removed third-party libraries still exposed through com.atlassian.confluence:confluence-java-api, and I was wondering if it is still safe to rely on those. Will they remain exposed and available to use without explicitly declaring them in our app’s pom.xml?
For example, org.codehaus.jackson:jackson-core-asl:jar:1.9.14-atlassian-6 and org.codehaus.jackson:jackson-mapper-asl:jar:1.9.14-atlassian-6 are now unavailable through com.atlassian.confluence:confluence but remain usable through com.atlassian.confluence:confluence-java-api.
No, the gray api removal will affect confluence-java-api also. The transitive dependencies exposed via that artifact will be removed in Confluence 8.8 (more specifically, the dependencies will be made “optional”, but the effect is the same, i.e. you’ll need to declare them yourselves as provided-scope dependencies)
Thank you for the suggestion about the versions being optional. That eases some pain in the meantime. I understand that when certain third-party dependencies are removed from the pom, vendors will definitely be required to add the version in order to be able to bundle them with the vendor product.
But what about Atlassian-specific core platform dependencies that have also been removed as transitive dependencies?
For example, given the core product features I mentioned earlier:
We cannot bundle them because they are part of the core product. They are not being removed from the OSGi exports (or at least they are not in the warning/deprecation list). The version numbers for each package are random and not in sync with the core product version, so we cannot use ${confluence.version} and the version must be updated manually every time Atlassian does a release.
Will we really have to provide version numbers for these artifacts starting from 9.0, as written above? If so, can this be fixed somehow? It does not seem to add anything (given that the packages are still being exported), and yet it creates more work and friction for vendors. Or is there some hidden package dependency we can add to pull these in?
Yeah, a few atlassian-specific transitive dependencies were removed, let’s take your examples one at a time:
atlassian-mail’s removal was a mistake. This is going to be reinstated in 8.7.1.
atl-plugins-webresource-common is an interesting case - it’s not intended for direct use from plugins, can you tell me what you’re using it for? We may have to reinstate this one in 8.7.1 also.
atlassian-util-concurrent - there are two variants of this, com.atlassian and io.atlassian. Neither are part of the platform, and the com.atlassian variant was removed from transitive dependencies, whereas the io.atlassian one remains.
As far as specifying version numbers is concerned, in general we recommend using the confluence-plugins-platform-pom as a BOM-style maven import. This removes the need for specifing versions.
Thanks for the clarifications. To provide more detail:
atl-plugins-webresource-common is an interesting case - it’s not intended for direct use from plugins, can you tell me what you’re using it for? We may have to reinstate this one in 8.7.1 also.
We’re using com.atlassian.plugin.servlet.ServletContextFactory.
atlassian-util-concurrent - there are two variants of this, com.atlassian and io.atlassian. Neither are part of the platform, and the com.atlassian variant was removed from transitive dependencies, whereas the io.atlassian one remains.
Are these two libraries interchangeable, meaning we can just switch to .io? (Why do the two variants exist?) Or since even the .io version is not “part of the platform” either, does that mean that using it is risky too?
Finally, is there any rough timeline for a 9.0 EAP? Is it worth providing feedback on the 9.0 milestone releases that have recently started appearing, or is it still too early?
While on the subject, the public UserAccessor#isDeactivated method was deprecated late in the 7.x series, with a suggested replacement of DisabledUserManager#isDisabled. But the DisabledUserManager bean does not seem to be accessible to plugins.
Trying to import the interface directly does not work, and neither does trying to do a named import of disabledUserChecker (which is what the actual bean seems to be named). Trying to import the underlying class CrowdDisabledUserManager also fails.
Am I doing something wrong, or is it possible that something needs to be addressed on the platform side?
Here’s another one. If the 9.0.0-m04 milestone is indicative of future efforts, I see that the confluence-rest-api package has also been withdrawn. Apps need to use the ServiceExceptionManager interface contained within, as indicated by the Atlassian tutorial for making apps compatible with read-only mode.
I admit that the number of issues is becoming a little bit concerning, because all of the above stem from just a single app, and I strongly suspect that a lot of other developers are not paying attention yet.
Removing third-party dependencies feels logically fine, but removing things under com.atlassian.* and equivalent looks really risky from a vendor point of view. I understand that the goal is ideally to prevent people from using these interfaces: but the reality is that basically nobody is creating new server/DC apps anyway, so this truly only impacts existing apps that were already using those interfaces, and it is really challenging to put the cat back in the bag properly.
I am maintaining a suite of long-lived Confluence Server/DC plugins that use a diverse assortment of com.atlassian.* APIs. I’m not yet totally caught up on compat work.
Plugins use all kinds of com.atlassian.* classes. There is no way, really, to know which change is going to break plugins. Any backwards incompat change is probably going to break someone… there is such a large population of plugins.
That is why some habits like deprecation of com.atlassian.* APIs without recommended replacements noted in the Javadoc can be so distressing. Plugins are using it all.
Maybe the pace of backwards-incompatible releases could slow down so that partners/vendors can stay caught up? I had just finished 8.6 compat work when 8.7.1 became public.
Also, I’m thinking I should probably go back and look at that 8.5.x release that recently came out with some backwards incompat changes.
(...) Package com.atlassian.mywork.service is deprecated and will be made unavailable for export to plugin com.playsql.requirementyogi in a future release
(...) Package com.atlassian.mywork.model is deprecated and will be made unavailable for export to plugin com.playsql.requirementyogi in a future release
Question #1. Those packages com.atlassian.mywork.service and com.atlassian.mywork.model are the API for the Workday tray (the inbox messages). Is there a suitable upgrade? Same for dom4j, which is a required argument of pluginController.addDynamicModule().
#2. Sources for Confluence 8.7 are unavailable, and Atlassian’s support refuses to provide them. If not,
How can we access what’s written in @deprecated javadocs, which generally points to the replacement method?
How can we access what’s written in @since javadocs, which was of great help to understand whether we’re able to use a method if we want to be compatible with Confluence 7.19, which is the standard at this time.
Shouldn’t Atlassian at least publish the Javadocs?
#3. Is ‘slf4j’ the correct logger in Confluence? It seems Confluence doesn’t export org.apache.log4j.Logger anymore.
#4. AMPS fails even if you import the libraries as <scope>compile</scope>
[WARNING] Rule 2: org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
make sure platform artifacts are not bundled into plugin
Found Banned Dependency: com.google.code.findbugs:jsr305:jar:3.0.2
Found Banned Dependency: org.apache.commons:commons-lang3:jar:3.14.0
Found Banned Dependency: com.google.guava:guava:jar:32.1.3-jre
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
I suppose we can just configure AMPS to ignore banned dependencies, but would it be possible to update AMPS to make it ignore dependencies that are not provided by Confluence anymore?
Hi Scott, sorry for the late reply. I can see you’ve seen our 9.0 is coming announcement, please share your feedback and questions in that thread, and we’ll triage the comments with the product team. It’s never too early for feedback so we can catch things early!
As for the rest of your questions , I’ve shared them with the team. They’ll respond directly in this thread shortly. Thanks for your patience.
We’re using com.atlassian.plugin.servlet.ServletContextFactory .
OK, that makes sense. The atl-plugins-webresource-common transitive dependency has been reinstated as of 8.7.2, its removal was causing too many unforseen problems.
Are these two libraries interchangeable, meaning we can just switch to .io?
The .io library replaced the .com one some time ago, but not enough effort was spent on our part to make sure we fully replaced one with the other. Since the .com one is no longer maintained, we’re treating that as an obsolete dependency. The .io one is still current and can be freely used as a library dependency.
, I’ve shared them with the team. They’ll respond directly in this thread shortly. Thanks for your patience.