10 Dec
2010
10 Dec
'10
3:31 p.m.
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
Jerome.
10 Dec
10 Dec
3:40 p.m.
On Dec 10, 2010, at 3:31 PM, Jerome Velociter wrote:
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
3:49 p.m.
New subject: [xwiki-devs] [VOTE] Introduce xwiki-legacy for backward compatibility code
On Fri, Dec 10, 2010 at 3:40 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Dec 10, 2010, at 3:31 PM, Jerome Velociter wrote:
You would prefer code in aspects in their respective modules ?
The strategy described by Thomas has the advantage to force people to
upgrade to new APIs since they cannot build unless they fix their code (or
depend on xwiki-legacy, but who would do that ? :)).
If you keep the backward compatibility in each module, you don't have that.
So in the end I think it's good, even though there will be two places indeed
(we cannot get rid of aspects either since there is compatibility code that
could not be written easily but with aspects).
Jerome.
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
4:47 p.m.
New subject: [xwiki-devs] [VOTE] Introduce xwiki-legacy for backward compatibility code
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
--
Thomas Mortagne
5:10 p.m.
New subject: [xwiki-devs] [VOTE] Introduce xwiki-legacy for backward compatibility code
+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
5029
days inactive
5029
days old
4 comments
4 participants
participants (4)
-
Caleb James DeLisle -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol