27 Mar
2012
27 Mar
'12
4:38 p.m.
+1,
this vote is a bit strange to me since I thought we're already doing
that (i.e. if it's not bugfix or code deletion ;) , there shouldn't be a
commit in the oldcore)
Thanks,
Anca
On 03/27/2012 04:18 PM, Denis Gervalle wrote:
On Mon, Mar 26, 2012 at 10:39, Vincent
Massol<vincent(a)massol.net> wrote:
Hi devs,
I see that we keep adding stuff regularly to oldcore and the reason is "my
code depends on oldcore so I cannot depend on oldcore in new modules".
First, this is not completely true. We have several modules that already
depend on oldcore.
Also we cannot wait indefinitely that the new model magically appears
(that won't happen… :)).
I think it's fine to depend on oldcore when a new module requires to use
the model and when the bridge (DAB) is not enough. However we need to be
careful about one thing: that oldcore itself doesn't use that new module.
So sometimes it will mean extracting stuff from oldcore into a separate
module so that it can use the other new module ;)
Personally I now think we need to continue splitting oldcore and it's more
important that we create new modules for specific domains, even if they use
old code and even if they use the com.xpn namespace when moving oldcode)
than keep everything as it is and make oldcore grow fatter…
Of course sometimes it may just be too complex but at least we should
consider it and when possible create new modules depending on oldcore.
WDYT?
Big +1 on this.
IMO, if you depends on oldcore for something larger than the bridge (which
IMO has grown too much), you may have in your module a bridge submodule to
isolate your oldcore dependency. This bridge submodule will simply provide
some internal bridge components. This allow your new module to be
itself independent from oldcore and it encourage isolation of problematic
part. If you want an illustration of this, you may have a look at the
xwiki-security-authorization-bridge module that will soon be merged on
master.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs