[Proposal] New Architecture for XWiki 2.0
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
forgot to cc Jason... -Vincent On Feb 12, 2007, at 12:06 AM, Vincent Massol wrote:
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
Vincent Massol wrote:
forgot to cc Jason...
-Vincent
On Feb 12, 2007, at 12:06 AM, Vincent Massol wrote:
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
Wow this is rather exciting! I've added a few links to the page to try to understand better the scope of Plexus in the area of component life-cycle management in comparison with OSGi et al. It's getting a bit clearer to me, although not crystal clear yet :-) Stéphane
I've added the rationale to moving to a component oriented architecture on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2: 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. I'll continue to add more information there. Thanks -Vincent On Feb 12, 2007, at 12:06 AM, Vincent Massol wrote:
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
Hi, I do think that Atom should be added to the remote call modular, especially Atom Publish Protocol. And SSO should also be included to make integration with other application easily (Make xwiki modular itself rather than only a standalone application). Thanks. On 2/12/07, Vincent Massol <vincent@massol.net> wrote:
I've added the rationale to moving to a component oriented architecture on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2:
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.
I'll continue to add more information there.
Thanks -Vincent
On Feb 12, 2007, at 12:06 AM, Vincent Massol wrote:
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
-- You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Best regards, Xin
Hi Xin, On Feb 12, 2007, at 10:56 AM, xin wu wrote:
Hi, I do think that Atom should be added to the remote call modular, especially Atom Publish Protocol. And SSO should also be included to make integration with other application easily (Make xwiki modular itself rather than only a standalone application).
Yes, I agree. However these are new features and they don't really require a new architecture (they can be implemented on the current architecture). I'd suggest you enter those in JIRA as feature requests so that they are not forgotten. Maybe we need a new thread about "what would users like to see in XWiki 2.0" (which is different from the architecture thread I think). Thanks -Vincent
On 2/12/07, Vincent Massol <vincent@massol.net> wrote:
I've added the rationale to moving to a component oriented architecture on http://www.xwiki.org/xwiki/bin/view/Idea/ ArchitectureV2:
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.
I'll continue to add more information there.
Thanks -Vincent
On Feb 12, 2007, at 12:06 AM, Vincent Massol wrote:
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
-- You receive this message as a subscriber of the xwiki- dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http:// www.objectweb.org/wws
--
Best regards, Xin
-- You receive this message as a subscriber of the xwiki- dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Hi, Sorry for the misunderstanding to this topic. Yes, I think it is important to add a new thread for advises from xwiki users. On 2/12/07, Vincent Massol <vincent@massol.net> wrote:
Hi Xin,
On Feb 12, 2007, at 10:56 AM, xin wu wrote:
Hi, I do think that Atom should be added to the remote call modular, especially Atom Publish Protocol. And SSO should also be included to make integration with other application easily (Make xwiki modular itself rather than only a standalone application).
Yes, I agree. However these are new features and they don't really require a new architecture (they can be implemented on the current architecture).
I'd suggest you enter those in JIRA as feature requests so that they are not forgotten.
Maybe we need a new thread about "what would users like to see in XWiki 2.0" (which is different from the architecture thread I think).
Thanks -Vincent
On 2/12/07, Vincent Massol <vincent@massol.net> wrote:
I've added the rationale to moving to a component oriented architecture on http://www.xwiki.org/xwiki/bin/view/Idea/ ArchitectureV2:
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.
I'll continue to add more information there.
Thanks -Vincent
On Feb 12, 2007, at 12:06 AM, Vincent Massol wrote:
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
-- You receive this message as a subscriber of the xwiki- dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http:// www.objectweb.org/wws
--
Best regards, Xin
-- You receive this message as a subscriber of the xwiki- dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
-- You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Best regards, Xin
participants (3)
-
Stéphane Laurière -
Vincent Massol -
xin wu