14 Oct
2006
14 Oct
'06
10 a.m.
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
14 Oct
14 Oct
2:42 p.m.
New subject: [xwiki-dev] [Proposal] Plugins and xwiki distributions
Hi Vincent,
thanks for your work.
On 10/14/06, Vincent Massol <vincent(a)massol.net> 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
3:22 p.m.
New subject: [xwiki-dev] [Proposal] Plugins and xwiki distributions
jeremi joslin a écrit :
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.
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
Hi Vincent,
thanks for your work.
On 10/14/06, Vincent Massol <vincent(a)massol.net> wrote:
Would it make sense for some bug plugins (like Lucene search) to have
their own trunk/branches/tags ?
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
------------------------------------------------------------------------
--
You receive this message as a subscriber of the xwiki-dev(a)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
--
Ludovic Dubost
XPertNet: http://www.xpertnet.fr/
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost AIM: nvludo Yahoo: ludovic
16 Oct
16 Oct
2:07 p.m.
New subject: [xwiki-dev] [Proposal] Plugins and xwiki distributions
-----Original Message-----
From: Ludovic Dubost [mailto:ludovic@xwiki.com]
Sent: samedi 14 octobre 2006 15:22
To: xwiki-dev(a)objectweb.org
Subject: Re: [xwiki-dev] [Proposal] Plugins and xwiki distributions
jeremi joslin a écrit :
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/
Hi Vincent,
thanks for your work.
On 10/14/06, Vincent Massol <vincent(a)massol.net> 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.
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.
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.
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.
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
1:56 p.m.
New subject: [xwiki-dev] [Proposal] Plugins and xwiki distributions
Hi Jeremi,
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.
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
-----Original Message-----
From: jeremi joslin [mailto:jeremi23@gmail.com]
Sent: samedi 14 octobre 2006 14:43
To: xwiki-dev(a)objectweb.org
Subject: Re: [xwiki-dev] [Proposal] Plugins and xwiki distributions
Hi Vincent,
thanks for your work.
On 10/14/06, Vincent Massol <vincent(a)massol.net> wrote:
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.
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.
6605
days inactive
6607
days old
4 comments
3 participants
participants (3)
-
jeremi joslin -
Ludovic Dubost -
Vincent Massol