On Fri, Sep 21, 2012 at 3:57 PM, Jeremie BOUSQUET
<jeremie.bousquet(a)gmail.com> wrote:
Hi,
I wonder if they are some specific recommendations, in addition to
what's described in [1] and [2] ?
My particular use-case, is to know if there is such a rule as to
create one maven module for one xwiki component, or if several
components can be grouped in the same maven module.
I could not names much Maven modules with only one component (some
macros maybe a few more stuff) so no it's really not mandatory.
Detailed description: for the xwiki-contrib-mailarchive-api, I started
from a monolithic class (@Component), then I started splitting it up
in several classes. While each of these sub-groups could be considered
components (highly related to the mail archive use-case, ie not
particularly re-usable), for now their life-cycle is managed by the
main Component (ie if one of them needs a query manager, it is not
injected by xwiki framework, but provided to it by the main
Component).
Would it be recommended to move to a whole component architecture, and
make all these sub-components Components managed by xwiki framework ?
Are there any limitations (perfs...) to do it that way ?
I'm pretty sure it's obvious to xwiki devs, but I prefer to ask.
For me the rule of splitting modules does not have much to do with the
components.
Usually I split when I expect to be able to use one of the module
without some of the others.
For example in Extension Manager you have a lots of module but most of
them are actually optional extensions to extension manager itself
(maven repositories handler, xwiki repositories handler, jar extension
handler, xar extension handler, etc...) and in each case behind it
there is potential uses case where it make sense to use some modules
without the other.
--
Thomas Mortagne