[Proposal] New Architecture for XWiki 2.0

[Vincent Massol]

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