Wicket 1.4

The CMS has upgraded to Wicket 1.4.x as the base technology.  All plugins that provide render services, i.e. those with a visual component, must make the transition themselves.  The main impact is that the getModel() method has been renamed to getDefaultModel() for components that do not have an obvious type of model.  A checkbox will use an IModel<Boolean> for instance.  See the wicket migration guide for details.

Plugin lifecycle

There were numerous problems with plugin inheritance, where base classes registered services that were then invoked by service trackers. This could cause subclasses to be invoked in one of their methods before construction completed. The updated plugin lifecycle should eliminate these problems.

These changes to the plugin lifecycle break backwards compatibility.  Only certain classes of plugins are affected.

Move cluster instantiation from construction to start phase 

There are some changes to the plugin lifecycle that break backwards compatibility.  Only certain classes of plugins will be affected.

The main impact of this change is that plugins that start clusters will likely have to move this to the start() method.  The reason is that they typically make some services available to the new cluster; after this change, the service will not be available to plugins during their construction.

The IActivator interface has been merged into the IPlugin interface. Plugins that use the RenderPlugin as their base class will not have to make any changes.  If they implement the IActivator interface as well, they will have to rename the start() method to onStart() and call super.onStart().

Plugins that implement the IActivator interface can remove this declaration.  Plugins that do not inherit from RenderPlugin can use the new Plugin class as a base class that should be stable in the face of future changes to the plugin lifecycle.