Summary

Oracle Coherence (formerly known as Tangosol Coherence) is the technology that provides clustering and distributed caching in Confluence. It has also been used for caching purposes in non-clustered Confluence deployments.

The Oracle Coherence technology was first incorporated into Confluence version 2.3. Since then, Atlassian has been able to distribute the Coherence technology library files via the following means:

• Included with all versions and distributions of Confluence downloadable from our web site since version 2.3, regardless of whether these were intended for clustered or single-server installations.
• From the Atlassian Maven repositories.

However, Atlassian is about to enter a new license agreement with Oracle over the Coherence technology. This means that from late September 2009, Atlassian will only be be permitted to distribute the Coherence library files to customers who have purchased a license for it (that is, a Confluence clustered license).

As a result, the following changes will occur:

• The next version of Confluence (3.0.1) will be released in two editions:
  • Standard — Editions of Confluence without the Coherence library files. Ehcache will replace the local caching functionality previously provided by the Coherence technology.
  • Clustered — Editions of Confluence containing the Coherence library files.
• Customers who have purchased a non-clustered Confluence license will only be able to download standard editions of Confluence from the Atlassian web site, whereas customers who have purchased a Confluence clustered license will be able to download clustered editions of Confluence.
• From late September 2009:
  • Standard editions of Confluence will be made available for each previous major releases of Confluence back to version 2.6. These will be available as Confluence versions 2.10.4, 2.9.3, 2.8.3, 2.7.4 and 2.6.3 and will be available to customers with non-clustered licenses.
  • All other previous versions of Confluence currently available from our download page (from 2.6 to 3.0 inclusively), will be re-released as clustered editions and will only be available to customers with Confluence clustered licenses.
  • The Coherence library files will no longer be available in any form from the Atlassian Maven repositories.
  • The installation files for all versions of Confluence prior to 2.6 (which are no longer supported) will be removed from the Atlassian web site and will no longer be available for download and installation.

What are the implications?

I am a Confluence customer with a non-clustered Confluence license, running Confluence 2.3 or later.

The Confluence distribution you are running will continue to function and if it is Confluence version 2.6 or later, be supported by Atlassian in accordance with our standard support policy.

However, if you upgrade to Confluence version 3.0.1 or later or obtain any Confluence version released after late September 2009, you will only be able to download and upgrade to standard editions of Confluence.

I run a customized installation of Confluence 2.3 or later and must build Confluence from source.

Confluence source code downloaded before late September 2009 requires that the Coherence library files are present in either your local or the Atlassian Maven repositories for automated Maven builds to complete successfully.

If you have Confluence source code downloaded before late September 2009 (excluding version 3.0.1) but conduct an automated Maven build of Confluence using this source code after this date, your build will fail if the Coherence library files are not available in your local Maven repository. This is because the Coherence library files will also not be available in the Atlassian Maven repository.

Hence, to build a customized installation of Confluence using this source code, we recommend that you locate the tangosol-3.3.jar and coherence-3.3.jar from the WEB-INF/lib directory of your own existing Confluence installation and install them into your local Maven repository using the following commands:

mvn install:install-file -Dfile=tangosol-3.3.jar -DgroupId=tangosol-coherence \
-DartifactId=tangosol -Dversion=3.3 -Dpackaging=jar
mvn install:install-file -Dfile=tangosol-3.3.jar -DgroupId=tangosol-coherence \
-DartifactId=coherence -Dversion=3.3 -Dpackaging=jar

Alternatively, you can download the sources for one of the new standard or clustered editions of Confluence and reapply your customizations. These will compile without any additional problems.

I am a plugin developer and wish to compile plugins against old or existing versions of Confluence

This will affect plugin developers in two ways:

1. When building a plugin, Maven will complain about the absence of the Coherence library files in the Atlassian Maven repository.
2. When using the Atlassian Plugin Toolkit to test a plugin, Maven will be unable to download the appropriate Confluence EAR-WAR distribution file (from the Atlassian Maven repository), against which to perform integration tests.

Therefore, we recommend that as soon as possible, plugin developers start compiling their plugins based on the new standard editions of Confluence (without the Coherence library files). Standard editions of Confluence will be binary-compatible with clustered editions and existing clustered instances of Confluence. Hence, plugins developed against standard editions of Confluence will also run on any clustered editions and existing clustered instances of Confluence.

I am a plugin developer concerned about API changes and multiple Confluence editions resulting from these changes

As long as you are using only Confluence APIs to develop plugins, your plugins will be binary compatible with both standard and clustered editions of Confluence. The interfaces of the Confluence CacheManager, Cache and ClusterManager will be the same in both editions of Confluence, although there will be only one important change from previous versions of Confluence.

In existing versions of Confluence, the ClusterManager exposes the Coherence InvocationService to allow clients to execute code or perform queries across all nodes of the cluster. This API will be unavailable in all standard edition versions of Confluence from version 3.0.1 back to 2.6. If your plugin uses this service (and Atlassian is not aware of any that do) you should instead use Confluence's RemoteEvent API to send messages to other cluster nodes and direct them to perform the work.

Also, if for some reason your plugin references some other Coherence classes directly (or imports the Coherence-specific implementations of the CacheManager, Cache or ClusterManager), you will need to rewrite your plugin to use the generic interfaces only.

I am a plugin developer and want to test my plugin against Confluence in a cluster

For testing purposes, you must own a Confluence clustered license and have access to a clustered Confluence installation (either an existing one or one based on the new Confluence clustered edition).