[Proposal] Plugins and xwiki distributions
Hi, I'd like to propose the following: 1) We create a single trunk/, branches/ and tags/ for plugins instead of having one per plugin which is a maintenance nightmare. This is what we're doing for Maven and it seems to be working fine. See http://svn.apache.org/repos/asf/maven/ 2) We move all plugins from core/main/src/java/c/x/w/plugin/* to xwiki/xwiki-plugins/trunk/*. That's provided there's no direct link between the core and the specific plugins. If there are then they'll need to be decoupled, possibly by introducing a components/ directory of components (which BTW could be used as the parent directory for hosting components if/when we decide to move to using a component-based architectire (OSGI, etc). 3) Each plugin build will result in a plugin jar and we add some or all of those jars to the distributions. As there's currently no online plugin downloading mechanisl we may need several distributions: a minimal one without any plugin, one with "core" plugins and one with all plugins. Or we could choose to have only 2: one without plugins and one with all plugins. WDYT? Thanks -Vincent
Hi Vincent, thanks for your work. On 10/14/06, Vincent Massol <[email protected]> wrote:
Hi,
I'd like to propose the following:
1) We create a single trunk/, branches/ and tags/ for plugins instead of having one per plugin which is a maintenance nightmare. This is what we're doing for Maven and it seems to be working fine. See http://svn.apache.org/repos/asf/maven/ If you think it's better, I agree. But how we do when we want to release a plugin? All the plugins have to be stable at the same time?
2) We move all plugins from core/main/src/java/c/x/w/plugin/* to xwiki/xwiki-plugins/trunk/*. That's provided there's no direct link between the core and the specific plugins. If there are then they'll need to be decoupled, possibly by introducing a components/ directory of components (which BTW could be used as the parent directory for hosting components if/when we decide to move to using a component-based architectire (OSGI, etc).
Yes, be carefull with the plugin with dependencies inside the code like the upload plugin. A solution, could be to change it to component, and doing a plugin to access to the functions of this component. Some plugins have dependencies between them also. for exemple in the GELC project, some the plugins are depends on the others. I think some plugins(actually on the core) are depend on others.
3) Each plugin build will result in a plugin jar and we add some or all of those jars to the distributions. As there's currently no online plugin downloading mechanisl we may need several distributions: a minimal one without any plugin, one with "core" plugins and one with all plugins. Or we could choose to have only 2: one without plugins and one with all plugins.
I prefer the first solution, but with something a little bit different, we distribute the core with the minimum required plugins, and we create a repository with all the jar of the plugin (as ibilio for maven), and a package with all the official plugins. What do you think? jeremi
jeremi joslin a écrit :
Hi Vincent, thanks for your work.
On 10/14/06, Vincent Massol <[email protected]> wrote:
Hi,
I'd like to propose the following:
1) We create a single trunk/, branches/ and tags/ for plugins instead of having one per plugin which is a maintenance nightmare. This is what we're doing for Maven and it seems to be working fine. See http://svn.apache.org/repos/asf/maven/ If you think it's better, I agree. But how we do when we want to release a plugin? All the plugins have to be stable at the same time?
Would it make sense for some bug plugins (like Lucene search) to have their own trunk/branches/tags ?
2) We move all plugins from core/main/src/java/c/x/w/plugin/* to xwiki/xwiki-plugins/trunk/*. That's provided there's no direct link between the core and the specific plugins. If there are then they'll need to be decoupled, possibly by introducing a components/ directory of components (which BTW could be used as the parent directory for hosting components if/when we decide to move to using a component-based architectire (OSGI, etc).
Yes, be carefull with the plugin with dependencies inside the code like the upload plugin. A solution, could be to change it to component, and doing a plugin to access to the functions of this component. Some plugins have dependencies between them also. for exemple in the GELC project, some the plugins are depends on the others. I think some plugins(actually on the core) are depend on others.
Does it mean components and plugins are different thing ? I tend to believe everything is a plugin. It's just that some plugins provide their own component API and implementation, some plugin implement some of the XWiki plugin hooks and some plugins do both. An example of a module being only a component would be the Store. An example of a module being only a plugin would be the SVGPlugin. An example of a module being both would be the FileUpload plugin. Plugins/Components will need to be extended to add hooks to the XWiki Action engine (currently based on struts). This would allow to transform more code that the core depends on to plugins/components. Maybe a module called "core-plugins" could make sense to package some mandatory plugin for XWiki to actually work at least as a wiki. Indeed we should prepare to implement a standard based component architecture.
3) Each plugin build will result in a plugin jar and we add some or all of those jars to the distributions. As there's currently no online plugin downloading mechanisl we may need several distributions: a minimal one without any plugin, one with "core" plugins and one with all plugins. Or we could choose to have only 2: one without plugins and one with all plugins.
I prefer the first solution, but with something a little bit different, we distribute the core with the minimum required plugins, and we create a repository with all the jar of the plugin (as ibilio for maven), and a package with all the official plugins.
If it's possible to minimize the amount of jar that would be great, especially for components. It could be a pain to have a jar for API and a jar for implementation, especially when XWiki core depends on that API. In this case it could be better to leave it in the core. The use of a core-plugins module could allow to reduce the amount of jars. Ludovic
What do you think?
jeremi
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
-----Original Message----- From: Ludovic Dubost [mailto:[email protected]] Sent: samedi 14 octobre 2006 15:22 To: [email protected] Subject: Re: [xwiki-dev] [Proposal] Plugins and xwiki distributions
jeremi joslin a écrit :
Hi Vincent, thanks for your work.
On 10/14/06, Vincent Massol <[email protected]> wrote:
Hi,
I'd like to propose the following:
1) We create a single trunk/, branches/ and tags/ for plugins instead of having one per plugin which is a maintenance nightmare. This is what we're doing for Maven and it seems to be working fine. See http://svn.apache.org/repos/asf/maven/ If you think it's better, I agree. But how we do when we want to release a plugin? All the plugins have to be stable at the same time?
Would it make sense for some bug plugins (like Lucene search) to have their own trunk/branches/tags ?
Sure but this can be done with a single branches/ and tags/ dirs. See https://svn.apache.org/repos/asf/maven/plugins/
2) We move all plugins from core/main/src/java/c/x/w/plugin/* to xwiki/xwiki-plugins/trunk/*. That's provided there's no direct link between the core and the specific plugins. If there are then they'll need to be decoupled, possibly by introducing a components/ directory of components (which BTW could be used as the parent directory for hosting components if/when we decide to move to using a component-based architectire (OSGI, etc). Yes, be carefull with the plugin with dependencies inside the code like the upload plugin. A solution, could be to change it to component, and doing a plugin to access to the functions of this component. Some plugins have dependencies between them also. for exemple in the GELC project, some the plugins are depends on the others. I think some plugins(actually on the core) are depend on others.
Does it mean components and plugins are different thing ? I tend to believe everything is a plugin. It's just that some plugins provide their own component API and implementation, some plugin implement some of the XWiki plugin hooks and some plugins do both.
There are some differences I think. A plugin is optional and doesn't have to be installed for XWiki to work whereas a component is mandatory and is not seen by the end users. A user will not be offered the choice to install a component. He'll only be offered the ability to install plugins. Other difference is that plugins can use components to implement their logic whereas plugins should not use/call other plugins. I guess they could be called the same but that would be confusing. I like Maven's organization: * components: https://svn.apache.org/repos/asf/maven/components/trunk/ * plugins: https://svn.apache.org/repos/asf/maven/plugins/trunk/ Maybe it's only a terminology issue but I think it makes thing clearer to name them differently and locate them in different places in the directory structure.
An example of a module being only a component would be the Store. An example of a module being only a plugin would be the SVGPlugin. An example of a module being both would be the FileUpload plugin. Plugins/Components will need to be extended to add hooks to the XWiki Action engine (currently based on struts). This would allow to transform more code that the core depends on to plugins/components.
Maybe a module called "core-plugins" could make sense to package some mandatory plugin for XWiki to actually work at least as a wiki.
Indeed we should prepare to implement a standard based component architecture.
3) Each plugin build will result in a plugin jar and we add some or all of those jars to the distributions. As there's currently no online plugin downloading mechanisl we may need several distributions: a minimal one without any plugin, one with "core" plugins and one with all plugins. Or we could choose to have only 2: one without plugins and one with all plugins.
I prefer the first solution, but with something a little bit different, we distribute the core with the minimum required plugins, and we create a repository with all the jar of the plugin (as ibilio for maven), and a package with all the official plugins.
If it's possible to minimize the amount of jar that would be great, especially for components.
All components would be included in the xwiki core distribution IMO.
It could be a pain to have a jar for API and a jar for implementation, especially when XWiki core depends on that API. In this case it could be better to leave it in the core. The use of a core-plugins module could allow to reduce the amount of jars.
Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Hi Jeremi,
-----Original Message----- From: jeremi joslin [mailto:[email protected]] Sent: samedi 14 octobre 2006 14:43 To: [email protected] Subject: Re: [xwiki-dev] [Proposal] Plugins and xwiki distributions
Hi Vincent, thanks for your work.
On 10/14/06, Vincent Massol <[email protected]> wrote:
Hi,
I'd like to propose the following:
1) We create a single trunk/, branches/ and tags/ for plugins instead of having one per plugin which is a maintenance nightmare. This is what we're doing for Maven and it seems to be working fine. See http://svn.apache.org/repos/asf/maven/ If you think it's better, I agree. But how we do when we want to release a plugin? All the plugins have to be stable at the same time?
No. Each plugin is released separately. See https://svn.apache.org/repos/asf/maven/plugins/. You'll see that tags and branches are performed on each plugin and not on all of them.
2) We move all plugins from core/main/src/java/c/x/w/plugin/* to xwiki/xwiki-plugins/trunk/*. That's provided there's no direct link between the core and the specific plugins. If there are then they'll need to be decoupled, possibly by introducing a components/ directory of components (which BTW could be used as the parent directory for hosting components if/when we decide to move to using a component-based architectire (OSGI, etc). Yes, be carefull with the plugin with dependencies inside the code like the upload plugin. A solution, could be to change it to component, and doing a plugin to access to the functions of this component. Some plugins have dependencies between them also. for exemple in the GELC project, some the plugins are depends on the others. I think some plugins(actually on the core) are depend on others.
Sure. I'm not going to do anything right now apart from moving the Alexa plugin. I'd just like to prepare the directory structures and that we all agree on how to handle plugins. Once we have that we can move each plugin independently one by one and discuss on a case by case basis.
3) Each plugin build will result in a plugin jar and we add some or all of those jars to the distributions. As there's currently no online plugin downloading mechanisl we may need several distributions: a minimal one without any plugin, one with "core" plugins and one with all plugins. Or we could choose to have only 2: one without plugins and one with all plugins.
I prefer the first solution, but with something a little bit different, we distribute the core with the minimum required plugins, and we create a repository with all the jar of the plugin (as ibilio for maven), and a package with all the official plugins.
Sounds good. -Vincent ___________________________________________________________________________ D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions ! Demandez � ceux qui savent sur Yahoo! Questions/R�ponses http://fr.answers.yahoo.com
participants (3)
-
jeremi joslin -
Ludovic Dubost -
Vincent Massol