10 Dec
2010
10 Dec
'10
5:10 p.m.
+1 for me.
I favor moving away from aspectj where possible because it is fundamentally not java and
the more
languages an application is written in, the more complex it becomes.
Caleb
On 12/10/2010 10:47 AM, Thomas Mortagne wrote:
On Fri, Dec 10, 2010 at 15:40, Vincent Massol
<vincent(a)massol.net> wrote:
On Dec 10, 2010, at 3:31 PM, Jerome Velociter wrote:
IMO you actually propose the opposite of what you want. Having a
xwiki-legacy module will really help to have "all compatibility stuff
in one place". Currently we put aspect in the module where the class
containing the deprected method is. We could have aspect (at least the
one that does not need to be in original class module) in this
xwiki-legacy module.
Hi,
As suggested by Thomas in the thread relative to renaming document events
(see http://xwiki.markmail.org/thread/62a3yaxiuosx4f6o ), I would like to
introduce a new module, xwiki-legacy, to host backward compatibility code
for modules. Rule would be that of course nothing should ever depend on
xwiki-legacy.
It will also help developers that relies on XWiki modules to upgrade to new
code when we deprecate things, since as soon as they upgrade their
dependency, they will not be able to build unless they fix the deprecated
calls (It would not be the case if each module would host its
backward-compatibility code).
First use case would be for renamed events. A listener in xwiki-legacy would
listen to the new document events, and notify the old corresponding ones.
WDYT ?
I'm +1
I'm +0 because I prefer to have all compatibility stuff in one place only and we
already have a place for that: in our aspects. Note that it's possible to put java
classes in aspects AFAIR.
This means we'll have 2 places:
- aspects
- xwiki-legacy
We'll need to document this on dev.xwiki.org.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs