Release Notes for XWiki 7.1 Release Candidate 1

Version 16.2 by Vincent Massol on 2015/05/30

This is the release notes for XWiki Commons, XWiki Rendering, XWiki Platform and XWiki Enterprise. They share the same release notes as they are released together and have the same version.

<insert description of release here>

New and Noteworthy (since XWiki 7.1M1)

Full list of issues fixed and Dashboard for <version>.

New performance report improvements

The debug performance tree has been made a bit more dynamic to be able to open/close nodes.



This feature is experimental and you should try it only for test purpose.

If no default distribution is configured, Distribution Wizard will now let you select the flavor to install.





  • The default document cache size has been increased from 100 to 500 elements
  • Minor visual consistency improvement of the tag cloud header of the LiveTable

See the full list of JIRA issues fixed in this release.

For Developers

Script oriented advanced extension search API

A new script oriented API has been added to use advanced extension search possibilities introduced in 7.0. See Extension Script Module.

Deprecated and Retired projects

<description of deprecated and retired projects>


The following dependencies have been upgraded:


  • Extension upgrade plan job now support checking specific list of installed extensions (instead of the top level installed extensions)
  • You can now disable the automatic start of Distribution Wizard with two new options.
  • It's possible to disable minification from configuration file. Set debug.minify to false.


The following translations have been updated: 

Tested Browsers & Databases

Performances tests compared to <last super stable version>

<a summary of the comparison with latest super stable version>

More details on <link to the test report>.

Known issues

Backward Compatibility and Migration Notes

General Notes

When upgrading make sure you compare your xwiki.cfg, and web.xml files with the newest version since some configuration parameters may have been modified or added. Note that you should add so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.

Mail API changes

The young mail API has been refactored to provide better and more detailed error reporting. 

The MailState enumeration has been extended to report more detailed mail state (prepare_success, prepare_error, send_success, send_error and send_fatal_error). The MailListener interface has been extended to provide more detailed event. Now each mail batch should use new independent listener. The listener receive the batch identifier of its own batch when the mail preparation starts (#onPrepareBegin()), and have to keep it for all subsequent events. Independent success and error events for both the prepare and send phases are provided for each message (#onPrepareMessageSuccess(), #onPrepareMessageError(), #onSendMessageSuccess(), #onSendMessagError()). Moreover, premature interruption of the prepare phase is caught and reported (#onPrepareFatalError). Inability of the send phase to retrieve a message for sending is also explicitly reported (#onSendMessageFatalError()).

There is now more than one message state representing an error, therefore, the MailStatusResult interface has been extended with a #getAllError() method to retrieve all message status in error. Moreover, the #getTotalMailCount()# may represent a partial total in case of failure of the prepare phase. In that case, it represents the number of mails sent to the send phase. As a consequence, #isProcessed()# and #waitTillProcess()# now considerer the batch to be processed when all successfully prepared mail has been sent, or failed to be prepared or sent.

The mail API is now tracking individual message based on the standard Message-ID headers, which made it fully compliant with RFC-822 WRT the mail identification. Caller that want to specify custom Message-ID may do so by extending MimeMessage to preserve the Message-ID of the message. Caller is also responsible to ensure that different messages are identified by unique message identifier.

Sending multiple messages with the same Message-ID is no more supported since it does not respect the RFC-822 standard. 

Reusing the same Message-ID for retrying a failed message is allowed and will be tracked by the same status if the batch identifier is also reused.

Issues specific to XWiki <version>

<issues specific to the project>

API Breakages

The following APIs were modified since <project> <version - 1>:

<clirr output here>

Get Connected