Release Notes for XWiki Enterprise 3.1

Last modified by Sergiu Dumitriu on 2012/02/17

This is the final release of XWiki Enterprise 3.1 (Roadmap). Over the course of the 3.1 cycle there were a few new features added and a lot of improvements in stability, code quality, and build practice. These release notes are compounded from the release notes from each release in the 3.1 cycle.

We've setup a Jira dashboard to present the work done for the whole 3.1 release. In summary, 172 issues have been closed by 9 committers (and other contributors providing patches), out of which 10 are new features, 40 are improvements and 96 are fixed bugs.

New & Noteworthy (Since XWiki Enterprise 3.0)

PDF Export Options

pdfExportOptions.png

If you export a wiki page to PDF using the Export menu you'll get a panel where you can configure some PDF export options. These options are defined in the PDF velocity templates and were previously available only as query string parameters to the PDF export URL.

Office Document Export

exportAsODT.png

If you configure your wiki to work with an office server (LibreOffice or OpenOffice) as described in the Office Importer Application you'll notice a new entry in the export menu (as long as you are connected to the office server). By default only the ODT (OpenDocument Text format) export is exposed but you can tweak the export URL to export to other office formats supported by your office server. For instance /xwiki/bin/export/Sandbox/WebHome?format=doc exports Sandbox.WebHome page to Microsoft Word's proprietary DOC format.

Auto Watch

Starting with 3.1 an automatic watch feature has been added and is enabled by default. That mean that each time a user do a major modification to a document or create one it's automatically added it the user watchlist. That way it's easy to follow future contribution to a document in which we are involved on.

Fork us on GitHub!

XWiki Enterprise 3.1 was the first version to be released from our new repository on github. We decided that git was sufficiently advanced over svn, our old version control system, that it warranted the effort spent to convert. If you are a developer who uses git then you already know what this means to you, you can participate in the XWiki development process by forking (git speak for copying) the source repository rather than being forced to provide patches to the benevolent committers who will accept or reject your patches at their pleasure. If you want to make something great but there's a part of the XWiki core which is holding you up, you can go right ahead and fork it into your own repository where you can fix it and share the results. We are excited to learn what you will create!

As a consequence, the structure of the repositories, the version numbers of the applications, plugins and build tools, as well as the structure of the projects on the issue tracker have changed. We moved all the plugins and applications inside the platform core, releasing them all together. This is also reflected in the issue tracker, where all the individual projects for each extension disappeared, since applications are now jira components inside the XWiki Platform project. This means that the version number confusion will stop, since everything has the same release version.

For developers

  • XCOMMONS-4: Implement support for JSR 330 Annotations
  • XCOMMONS-10: Add support for injecting Logger with @Inject. Now you can have the XWiki Commons logging implementation inserted into your module using dependency injection.
  • XWIKI-6103: Introduce APIs using References for context user
  • XWIKI-6213: Add custom properties to extensions
  • XWIKI-6563: Provide statistic information about clustered nodes

Code Maintenance

Upgrades

Miscellaneous

  • Code macro now supports velocity syntax
  • New Success Macro. For example: tick Success macro, you can access this by writing {{success}}text here{{/success}}
  • XWIKI-6518: Added edit menu for inline editing mode.
  • XWIKI-6174: Make the attachment mimetype labels translatable
  • XWIKI-116: Added the ability to dictate what mode documents should be edited in by default on a document by document basis.
  • XWIKI-6599: Support for suggestion sources to provide custom icon/images for individual result entry
  • Lots of bug fixes, see a full list of issues closed in the 3.1 development cycle.

Translations

  • The translations for ca, cs, se, es, fr, gl, it, lv, nl, pt, ro, ru, sk, sv, si, uk, zh, zh_TW were updated.

Known issues

  • Bugs we know about
  • An error has slipped in on the Main.WebHome page where a Watchlist Object has been added by mistake. You should edit this page and remove it. A side effect of having it may cause some NullPointerException to be displayed in the console but without adverse effects.

Test Report

You can check the manual test report to learn about what was tested and the results on various browsers.

Backward Compatibility and Migration Notes

Java 1.6

XWiki Enterprise 3.1 Milestone 2 and all subsequent versions will be compiled with Java6, Java5 is no longer supported.

Deprecated XClass database tables removed

In XWIKI-6624 a set of database tables and their supporting infrastructure were removed. These tables held XWiki Class information but since XWiki 1.0, the table method of storage has been deprecated and non-default. If upgrading from a pre-1.0 version of XWiki, it is important to make sure you are using the XML XWiki class storage and not the database tables first.

WYSIWYG Editor Configuration

In order to implement XWIKI-6618 we changed the format of the menu bar configuration. If you exclude the XWiki.WysiwygEditorConfig page when you upgrade your wiki pages (which you should do in order to preserve your WYSIWYG editor configuration) then you have to:

  1. edit the XWiki.WysiwygEditorConfig page with the object editor
  2. remove deprecated properties (you have to do this because we changed the type of the Menu Bar property to accommodate the new format)
  3. change the value of the Menu Bar property to use the following JSON format:
    [{
     "feature" : "link",
     "subMenu" : ["linkEdit", "linkRemove", "linkWikiPage", "linkAttachment", "|", "linkWebPage", "linkEmail"]
    },
    {
     "feature" : "image",
     "subMenu" : ["imageInsertAttached", "imageInsertURL", "imageEdit", "imageRemove"]
    },
    {
     "feature" : "table",
     "subMenu" : ["inserttable", "insertcolbefore", "insertcolafter", "deletecol", "|", "insertrowbefore", "insertrowafter", "deleterow", "|", "deletetable"]
    },
    {
     "feature" : "macro",
     "subMenu" : ["macroInsert", "macroEdit", "|", "macroRefresh", "|", "macroCollapse", "macroExpand"]
    },
    {
     "feature" : "import",
     "subMenu" : ["importOffice"]
    }]

If importing XWiki.WysiwygEditorConfig or XWiki.WysiwygEditorConfigTemplate fails then you have to follow this steps in order to update the WYSIWYG editor configuration:

  1. Open XWiki.WysiwygEditorConfig and XWiki.WysiwygEditorConfigTemplate in the object editor, and remove the XWiki.WysiwygEditorConfigClass objects from them
  2. Open XWiki.WysiwygEditorConfigClass page in the class editor, delete the menuBar property, and add it again as a String property
  3. Open XWiki.WysiwygEditorConfig and XWiki.WysiwygEditorConfigTemplate in the object editor, add and then remove again an object of type XWiki.WysiwygEditorConfigClass
  4. Import the XWiki.WysiwygEditorConfigClass, XWiki.WysiwygEditorConfig and XWiki.WysiwygEditorConfigTemplate pages from the upgrade XAR

If you didn't try and failed to import these documents already, it's simpler to just delete XWiki.WysiwygEditorConfig and XWiki.WysiwygEditorConfigTemplate first, then continue with a normal import.

Removed Plugins

These plugins are very old and were almost never used.
Unless your xwiki.cfg file contains one of:

  • com.xpn.xwiki.plugin.TablePlugin
  • com.xpn.xwiki.plugin.PatternPlugin
  • com.xpn.xwiki.plugin.test.TestPlugin

You are verifiably unaffected by this change.
These plugins are still available in the retired source code repository.

XWikiPreferences class preferences

If you have an existing wiki and you are upgrading to 3.1, you will not experience any changes. If you are installing a new wiki, the following preferences will not be available to the XWikiPreferences or WebPreferences objects. If you are a developer of an XWiki based application which depended on one of these settings, you will need to upgrade your application to make it compatible with new 3.1 XWiki installations.

  • convertmail
  • editbox_height
  • editbox_width
  • macros_groovy
  • macros_languages
  • macros_mapping
  • macros_velocity
  • macros_wiki
  • macros_wiki2
  • menu
  • notification_pages
  • pageWidth
  • renderXWikiGroovyRenderer
  • renderXWikiRadeoxRenderer
  • renderXWikiVelocityRenderer
  • webbgcolor

General Notes

If you're running in a multiwiki setup you'll also need to define the property xwiki.store.migration.databases=all to your xwiki.cfg file or explicitly name all databases to be migrated as in xwiki.store.migration.databases=db1,db2,....

You may also want to import the default wiki XAR in order to benefit from the improvements listed above.

Always make sure you compare your xwiki.cfg file with the newest version since some configuration parameters were added. Note you should add xwiki.store.migration=1 so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.

API Breakages

No APIs were modified since XWiki Enterprise 3.0.

Tags:
Created by Caleb James DeLisle on 2011/06/16
    

Get Connected