Description

• Executive Summary
• Rationale
• Proposal

Executive Summary

Move to a component-oriented architecture.

Rationale

Moving to a component-oriented architecture will yield the following benefits:

• Ability to decouple the different pieces of XWiki and make it more modular. This is good for extending XWiki. Right now it has reached a point where it's hard to extend without breaking something
• Make it easier to contribute to XWiki. With components, contributors do not have to understand the whole thing. They can focus on modifying the component of their choice without knowing the rest. It's also easier to extend the platform.
• Improve our tests. Component-orientation brings IOC and thus the ability to write unit tests more easily as the objects acted upon are passed to the component and thus can be easily mocked.
• Ability to create different distributions of XWiki easily: for example for mobile devices, for the P2P XWiki, etc. In the same topic, ability to embed XWiki in other software becomes possible
• Ability to dynamically load XWiki extensions (java classes, external jars, etc) without restarting XWiki. This feature is brought by the component managers. 

Proposal

• Component-oriented architecture using a Component Manager
• Each component group (set of components for implementing a concept) is separated in its own build module and generates a JAR
• Make the component 100% independent of the Component Manager used
• Register the Component Manager using a Servlet Context Listener
• Question: Should we use existing components from the Component Manager implementation? If so the question is whether it'll work with other Component Managers?
• Packages:
  • com.xpn.xwiki. (which BTW I'd like to change to org.xwiki.). For example: com.xpn.xwiki.rendering, com.xpn.xwiki.logging, com.xpn.xwiki.storage, etc
  • A special com.xpn.xwiki.component package for storing classes/interfaces required by the component manager and for users. For example: Loggable, Configurable, etc + possibly component manager abstraction (in case for example we need to do lookups that'll work in Plexus, OSGi, etc).
  • Internal APIs go in com.xpn.xwiki.<component domain>.internal.*
    • Note: We can provide a Velocity Uberspector to prevent using internal packages if we want
• For components that have several implementations (for example renderers), separate the rendering component in one JAR and the various implementations in another JAR (one JAR per implementation). In Maven this means different build modules for each.

Implementation Details

• Use Plexus as the Component Manager (each component JAR has a META-INF/components.xml file that configures Plexus). The reason for choosing Plexus:
  • Plexus supports full decoupling, i.e. it's possible not to have any plexus import in our component code. It's thus possible to switch to another component manager easily if need be
  • Plexus is a mature component manager
  • Jason Van Zyl (Plexus author) is willing to help XWiki migrate
  • Plexus is compatible with several other component managers (through its Personality feature), and an OSGi bridge is being developed too.
• Future: Make the components OSGi-compliant (each component JAR has a META-INF/Manifest with OSGi configuration in there)
• Start creating a branch in XWiki (xwiki/xwiki/branches/XWIKI_2_0) for working on this.
• Idea: It would be nice to merge back the work progressively (if possible) on the trunk. It might be possible as we have a public API which we could keep and only change the underlying implementation for now, thus preserving backward compatibility (except possibly for plugin writers but that's less of an issue IMO).

List of Components Required

• Rendering and Renderers
• URL Management (Portlet, Servlet, XMLRPC, etc)
• Storage + Query/Search (JCR, DB/Hibernate, Subversion, etc)
• Authorization (JAAS, DB, etc)
• Authentication (JAAS, DB, LDAP, etc)
• User/Groups Services
• Document Services
• Configuration Services (dynamic configs in DB for example)
• Remote Calls Services (XMLRPC, SOAP, Email, etc)
• Attachment Services
• Statistics Services
• Cache Services
• Logging
• Wiki Services (like getWikis() for a farm, etc)
• Container Services (adaptation layer for Servlet, Portlet, etc)
• I18N Services
• Notifier Services (SMTP, IRC, SMS, etc)
• Scriptable API (the context/vcontext should be automatically populated)
  Lots of these services should offer extension points so that it's possible to write extensions against them. The idea is to remove the need for a Plugin interface that would list all the possible extension points. Instead it should be each component offering those extension points. Alternatively the extension would completely replace or wrap an existing component.
  

Todos

• Create Architecture diagram listing all components required
• Define the interface for each component
• Idea: Start with the Rendering component and the Renderers (Velocity, Radeox, Doxia, etc). Note: We need ordering as a page is going to be rendered in sequence by all the renderers (unless a renderer says not to continue the chaining)

Links

• Plexus
• Plexus five minute tutorial
• Plexus Javadocs
• Plexus and Java annotations
• Plexus - Why use components
• Brett Porter on Plexus and Maven dependency model versus OSGi's
• Introduction to IOC
• IOC by Martin Fowler
• Component life-cycle management - Plexus versus OSGi: http://www.mail-archive.com/[email protected]/msg10441.html http://www.mail-archive.com/[email protected]/msg06460.html
• OSGi