Hi XWiki developers, I'd like to start a discussion on the XWiki 2.0 Architecture. I've put my thoughts on http://www.xwiki.org/xwiki/bin/view/Idea/ ArchitectureV2 (sorry I haven't explained a lot yet so I guess you'll have to be familiar with component-oriented development to understand fully what it means - Do not hesitate to ask questions if there's something not clear :-)). I'm listing down here the content of that page so that we can discuss it here more easily. I'd also like to start working and experimenting with it. Actually my goal is to do a POC to see what level of changes would need to be brought to the core and more importantly whether or not we can keep the backward compatibility and thus start refactoring in the 1.x code base rather than start a complete new 2.x branch. In any case I'd like to create a XWIKI_2_0 branch tomorrow for starting the experimentation. In addition Jason Van Zyl (whom I'm cc- ing and who's the creator of Maven, Velocity, Turbine, Plexus and other OSS projects ;-)) is keen to work with us on this and would also like experimenting ASAP. I'm thus proposing to give him write access to that XWIKI_2_0 branch. Let me know what you think Thanks -Vincent ----------- 1.1 Ideas * Component-oriented architecture using a Component Manager * Each component group (set of component 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? 1.1 Implementation Details * Use Plexus as the Component Manager (each component JAR has a META- INF/components.xml file that configures Plexus) * 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). 1.1.1 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) 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. 1.1 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) ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com