Release Notes for XWiki Enterprise 4.0 Milestone 1

Version 1.2 by Thomas Mortagne on 2012/03/12

This is the first milestone of the XWiki Enterprise 4.0 version (Roadmap). This release brings reduced document database id collision and quite a few improvements and bug fixes.

New and Noteworthy (since XWiki Enterprise 3.5 version)

Extension Manager improvements

TODO

For developers

Extension Manager moved to commons

Everything not not specifically related to wiki is now part of xwiki-commons. That means that anyone can get all Extension Manager features (easy live JAR installation/uninstallation from remote repositories, dependency management, etc.) in any Java application.

Classloader module moved to commons

Mostly been moved as Extension Manager dependency but also useful on it own as a tool to dynamically add new URL in a classloader at runtime.

Component related improvements

Role moved from Class to Type

In order to support parameterized role like DocumentReferenceResolver<String>, all the APIs of ComponentManager and Component descriptors has been changed to take Type instead of Class. All the old API are still here and working but deprecated.

ComponentRole is deprecated

You should now use @Role instead of @ComponentRole. The difference is that when using @Role the generic parameters will be taken into account as part of the role while with @ComponentRole the role stay the Class of the component role so be careful when you do this change, it might break everything if you don't want to take into account parameters (that's why a new annotation has been introduced instead of changing the behavior of ComponentRole).

References resolver/serializer and Provider now support parameter type as part of the role

This mean that declaring or injecting a such component no longer require any hint unless you want to provide/inject a variant for the same type.

Here are some example. Instead of:

@Inject
@Named("reference/default")
private DocumentReferenceResolver<EntityReference> resolver

@Inject
@Named("reference/current")
private DocumentReferenceResolver<EntityReference> resolver

@Inject
@Named("sometypeprovider")
private Provider<SomeType> resolver

you will write

@Inject
private DocumentReferenceResolver<EntityReference> resolver

@Inject
@Named("current")
private DocumentReferenceResolver<EntityReference> resolver

@Inject
private Provider<SomeType> resolver

All reference resolver and serializer provide static variables with the Type for both String and EntityReference. For example you can write:

DocumentReferenceResolver<EntityReference> resolver = componentManager.lookupComponent(DocumentReferenceResolver.TYPE_REFERENCE, "current")

Bug fixes and improvements

  • XE-1096 The attachment selector should also work with the /edit/ action in 'Inline form' edit mode
  • XE-1105 Default class sheet doesn't display correctly the class title
  • XWIKI-7411 Cannot import a XAR containing %3A in its file name
  • XWIKI-6305 Keep the current user in the administration application when editing user details
  • XWIKI-7462 Improve the Profile breadcrumb to be more user friendly
  • XWIKI-7484 Write a log line in the console instructing the user to open XWiki in a browser

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

For Developers

  • XCOMMONS-94 Set the minimum required Maven version (3.0) to build XWiki in the POM
  • XWIKI-7502 Replace notion of Container's ApplicationContext with the notion of Environment
  • XWIKI-7476 Sheets need to be able to display the title of the document they are applied to
  • XWIKI-7526 Enable Infinispan JMX mbeans by default for runtime monitoring of XWiki caches
  • XWIKI-7504 Files within WEB-INF directory readable by using Velocity
  • XE-1108 Provide tomcat5 and tomcat7 based Debian packages

Upgrades

The following dependencies have been upgraded:

Translations

The following translations have been updated:

Tested Browsers

TODO

Known issues

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

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 all the improvements listed above.

Always make sure you compare your xwiki.cfg and xwiki.properties files with the newest version since some configuration parameters were added. Note that 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

The following APIs were modified since version 3.5:

TODO

Get Connected