Preparing for Confluence 6.0
This documentation is intended for Confluence developers who want to ensure that their existing plugins and add-ons are compatible with Confluence 6.0, and to learn about the new features for developing add-ons in Confluence 6.0.
The feature you've all been waiting for is ready for a test drive! Read more about how collaborative editing works for users or head to Preparing for Confluence 6.0 to see how it works under the hood and find out how you can make sure your add-on is compatible.
These are early milestones, and are not suitable for production sites (no matter how much you may be tempted) - so give it a run in a test site only.
You may need to give your test server more memory than for previous Confluence releases. In this EAP release Synchrony's max heap size is 1 GB. As of Confluence 6.0.0-m77 this is configurable via the
reza.memory.max system property.
Ports and firewalls / proxies
Your firewall / proxies must be configured to allow:
- WebSocket connection (if you're using NGINX see Using NGINX as a WebSocket Proxy for more info). As of Confluence 6.0.0-rc2 an experimental XML HTTP Request (XHR) fallback feature is available by setting the system property
synchrony.enable.xhr.fallback=true. This may be used if it is discovered in production that some users can't access Confluence via WebSockets. Note that the XHR fallback isn't compatible with using the Synchrony proxy via Confluence. See CONF-44250.
- Port 8091 for Synchrony's connections. We are in the process of developing an internal Synchrony proxy that will mean customers don't need to open port 8091. This will be available in a future milestone.
- As of Confluence 6.0.0-m77 we support running Confluence with a reverse proxy. See How to use NGINX to proxy requests for Confluence for an example of how to include Synchrony.
HTTP and HTTPS
- Early EAP releases only supported the default HTTP connector configuration. If you've customized the Tomcat connector configuration (as outlined in Running Confluence Over SSL or HTTPS for example) collaborative editing will likely fail. This was resolved in later milestones.
- As of Confluence 6.0.0-m77, we support running Confluence with a reverse proxy with SSL. See Running Confluence behind NGINX with SSL for more information. Updated docs for Apache mod_proxy will be available soon.
Collaborative editing will fail with an error if:
- you're using an unsupported or custom database driver. See Database JDBC Drivers for the list of drivers we support.
- you have a custom datasource connection, particularly if you've used a
driverClassNamethat is not in our list of supported database JDBC Drivers. See How to convert a datasource to a direct JDBC connection to switch to a direct JDBC connection, and Troubleshooting External Database Connections for more info.
Not yet available for Data Center
This EAP release is not ready for Confluence Data Center. We'll make this available in a future milestone.
Confluence 6.0.0-m77 contains the upgrade task that will remove the documentation theme, and switch any spaces using the documentation theme, to the default theme. See Documentation theme migration FAQ for more information.
Confluence 6.0.0-m68 contains an upgrade to Guava 18.0. The previous version of Guava being used in the product was 11.0.2, which is a very old version released back in 2011.
Full release notes from version 11 to 18 can be found at https://github.com/google/guava/wiki/ReleaseHistory.
There are a lot of breaking changes between 11.0.2 and 18.0, but the most noticeable ones are listed below.
- Cache becomes LoadingCache
Cache was deprecated in 11.0.2, but was still usable. It has now been fully removed, and all usages should be replaced with
CacheBuilder.build(). See https://github.com/google/guava/wiki/Release11 for more information.
- Cache no longer supports MapMaker
Details on migrating from MapMaker to a standard LoadingCache can be found in https://github.com/google/guava/wiki/MapMakerMigration.
- Stopwatch changes
Stopwatch constructors have been removed in favour of
elapsedXXXmethods have also been removed in favour of
stopwatchInstance.elapsed(TimeUnit). See the notes in https://github.com/google/guava/wiki/Release15.
Confluence 6.0.0-m68 contains an upgrade to Hibernate 5.2.2. The previous version of Hibernate being used in the product was 2.1.8, which is a very old version released over a decade ago.
A compatibility layer has been introduced to adapt hibernate 2 interfaces to hibernate 5, and to transpile HQL queries to work around common incompatibilities.
A full change log from version 2.1.8 to 5.2.2 can be found at https://github.com/hibernate/hibernate-orm/blob/4.3/changelog.txt and https://github.com/hibernate/hibernate-orm/blob/master/changelog.txt.
Other library upgrades
We've upgraded the following libraries and plugins:
- Hibernate 5
- Google gson 2.7
- Atlassian gzipfilter 3.0
- AUI 5.10.1
- Atlassian Gadgets 4.2.7
- SLF4 1.7.21
- JSON 0.11
- Atlassian http 1.1.4
- commons codec 1.10
- commons validator 1.5.1
- Botocss 6.3
- Atlassian beehive 0.2.1
- Active Objects 1.2.2
Plans to remove deprecated functions
We plan remove a number of previously deprecated functions in Confluence 6.0. More information will be provided here once the work is complete.
Change to plugin license storage plugin
We have removed
com.atlassian.upm:plugin-license-storage-plugin:2.15.3 from Confluence 6.0 as its functionality is entirely provided by UPM now and the old plugin was incompatible with Guava 18.
If you see errors like
Could not initialize class com.atlassian.upm.osgi.impl.Versions you'll need to update your add-on to depend on a version of UPM that provides a recent version of the third party license API. See https://developer.atlassian.com/market/add-on-licensing-for-developers/tutorial-adding-licensing-support-to-your-add-on for how to add licensing support to your add-on for Confluence 6.0.
If you were using classes like
com.atlassian.upm.osgi.impl.Versions for any other reason, it is still available via the following dependency
<dependency> <groupId>com.atlassian.upm</groupId> <artifactId>upm-common</artifactId> <version>2.21.3</version> <scope>provided</scope> </dependency>
Atlassian Gzip Filter is no longer available to plugins
com.atlassian.gzipfilter* is no longer available to plugins. Any plugin using the shaded version of
com.atlassian.gzipfilter.org.commons.lang should upgrade to commons-lang3 following the standard upgrade guide on the Apache commons website. This typically involves simply changing the imports from
org.apache.commons.lang3, which is exported by Confluence.
Changes to slf4j internals
org.slf4j.bridge are no longer exported. Plugins can remove usages of slf4j internals and also remove declared imports of the internals in the
<Import-Package> section of the maven-confluence-plugin configuration in pom.xml as
slf4j will still work perfectly without them in a plugin.
XML api changes
- Confluence no longer uses the
com.sun.bindimplementation of JAXB (from
com.sun.xml.bind:jaxb-impl) and now just uses the version bundled in Java 8. Plugins no longer need to import the implementation packages. Confluence also no longer exports a dependency on
javax.xml.bind:jaxb-api. Plugins can depend on the version bundled in Java.
- Confluence now exports enough packages from
org.w3c.domfor its batik jars to be usable from a plugin, and
org.w3c.dom.xpathis now correctly exported from the bootstrap loader. As part of this change, Confluence no longer exports a dependency on
xml-apis:xml-apis, but instead exports
org.apache.xmlgraphics:batik-ext. Some plugins may have compilation errors due to this change.
- Confluence no longer exports
- Confluence no longer provides an implementation of the interface
net.sourceforge.cssparser:cssparser. Only the implementation in
org.apache.xmlgraphics:batik-css:1.7is available from the system bundle by default.
Reminder to Require Dependencies
As we continue to move to a more modular design for our front end resources, it becomes even more important to make sure you are requiring all the dependencies that your plugin needs. Some resources that may have been included on the page by chance previously may no longer be included or might be out of order or included later, because some of them may be loaded asynchronously for the individual features or components that require them. This gives us a performance benefit as it gives a faster page load time and also avoids loading resources that are not always required.
What this means is that you should always explicitly define the dependencies required for your resources in your atlassian-plugin.xml, especially for AUI Components that are not included in Core. For example, on https://docs.atlassian.com/aui/latest/docs/date-picker.html, you can see that this dependency needs to be explicitly required in your atlassian-plugin.xml file: <dependency>
com.atlassian.auiplugin:aui-date-picker</dependency>. The good news is that if you are already doing this, you shouldn't have anything to worry about.