The XWiki Ecosystem
There are various XWiki Products that are part of the XWiki Ecosystem as shown on the diagram below:

In the sections below we will cover the Architecture for XWiki Products that are based on a Container (i.e. excluding XWiki Eclipse, XWiki Office and XWiki OpenOffice).
The XWiki Platform offers common APIs and common User interface elements. Products cherry pick elements from the Platform and extend them to create a runnable distribution.

XWiki Core is a single historic JAR that we are splitting into several distinct modules (see below for modules that have been separated already) and that currently implements the following features:
- Model: All the classes representing the wiki model, i.e. the following notions: Document, Space, Wiki, Classes/Objects, Attachments and more.
- Cache: This is the old cache service, which has been replaced by the new Cache Module.
- XWiki Syntax 1.0 Rendering: This is the old service for rendering XWiki Syntax 1.0 which we keep for backward compatibility so that existing users can keep using the XWiki Syntax 1.0. For all other syntaxes there's now a new Rendering Module.
- Localization: Handles translations in various languages. A new Localization module is under development that will replace this old module.
- Notification: Handles event regsistration and distribution. For example code can subscribe to receive an event when a new document is created. This is under replacement by the new Observation Module (no documentation yet).
- Exports (PDF, RTF, XAR). In the future this will be done by implementing specific Renderers in the new Rendering Module.
- Security: Authentication & Authorization handling.
- User Management
- ... and more
For more information on how to develop Plugins see
this tutorial.
Plugins that are in their own JAR:
Plugins that are still located in the XWiki Core JAR:
- Tag Cloud
- Captcha
- Charts
- Diff
- Feed
- File Upload
- Google
- GraphViz
- Image
- LDAP
- Mail
- Packaging
- Query
- Rights Manager
- SVG
- User Directory
- Zip Explorer
In addition to the listed plugins above which are created and maintained by the XWiki development team, others plugins have been contributed and can be installed. The full list of available plugins is available on the Extensions wiki.
A module offers services in a given domain. Modules are the equivalent of Plugins but using the new XWiki component-based architecture. Here's the list of implemented modules:
In addition to the listed applications above which are created and maintained by the XWiki development team, others applications have been contributed and can be installed. The full list of available applications is available on the Extensions wiki.
Extending XWiki
As a developer there are various ways to extend the XWiki platform as shown on the diagram below:
- You can write your own application completely and reuse XWiki services such as Rendering, WYSIWYG editor, Rights management, Versioning, etc (see above for the list of Services). If you choose this path you'll need to provide a UI.
- You can use XWiki Enterprise or other Products and extend them by extending the Platform as described in the next section.

The XWiki Platform can be extended by:
- Writing scripts in wiki pages
- Writing Applications (set of wiki pages)
- Writing Plugins in Java
- Writing Modules (ie. set of components) in Java
- Writing new Skins or extending existing ones
- Extending existing Service APIs when they provide extension points. You'll need to check the documentation for the service you wish to extend to know if it provides extension points. For example:

Extending XWiki Remotely

If you want to control completely the UI you can call (some) XWiki services remotely using REST, XMLRPC or GWT.
For other services not offering a remote API you can embed them as libraries (JARs) or create new REST/XMLRPC/GWT extensions.
Specific Architecture items
The sections below will be moved to their own Modules in the future.
Understanding how HTTP requests are handled

HTTP Request Analysis
For each HTTP request, during the XWiki initialization phase, XWiki analyzes the URL to extract information from it. For example the http://www.xwiki.org/xwiki/bin/view/Main/WebHome URL generates the following information:
- The URL path contains /view/ and thus the ViewAction.java class is executed (configured in struts-config.xml) and called by the Struts Action, itself configured in web.xml.
- the wiki is the main wiki (since the server name starts by www)
- ViewAction specifies that view.vm will be rendered using Velocity
- the space asked is Main and the document's name is WebHome