[xwiki-devs] [VOTE] Generalize concept of legacy module to XWiki Commons and even more generally
Hi devs, I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise). The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module. My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module. Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step. It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it). Here's my +1 to follow this practice across our code base and to document it on xwiki.org Thanks -Vincent
On Tue, Sep 27, 2011 at 1:58 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Actually there was a use case even before that since https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik... should be in commons ;)
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, Sep 27, 2011 at 13:58, Vincent Massol <[email protected]> wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
I know this will be another thread, but why not keep legacy and have a build without legacy stuff. This build could also be a good test that we really do not rely on legacy stuffs.
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Tue, Sep 27, 2011 at 3:55 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Sep 27, 2011 at 13:58, Vincent Massol <[email protected]> wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
I know this will be another thread, but why not keep legacy and have a build without legacy stuff. This build could also be a good test that we really do not rely on legacy stuffs.
That's xwiki-debug-eclipse ;)
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 09/27/2011 09:55 AM, Denis Gervalle wrote:
On Tue, Sep 27, 2011 at 13:58, Vincent Massol<[email protected]> wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
I know this will be another thread, but why not keep legacy and have a build without legacy stuff. This build could also be a good test that we really do not rely on legacy stuffs.
+1, the legacy module should only be pulled in during releases. The snapshots should be built without them, and the ci tests should be run on a legacy-free build
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
+1
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Sep 29, 2011, at 3:14 AM, Sergiu Dumitriu wrote:
On 09/27/2011 09:55 AM, Denis Gervalle wrote:
On Tue, Sep 27, 2011 at 13:58, Vincent Massol<[email protected]> wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
I know this will be another thread, but why not keep legacy and have a build without legacy stuff. This build could also be a good test that we really do not rely on legacy stuffs.
+1, the legacy module should only be pulled in during releases. The snapshots should be built without them, and the ci tests should be run on a legacy-free build
Well ideally we would need to verify that legacy modules continue to work. So ideally we would special functional tests for legacy modules too with pages using old stuff to make sure they still work. Not very easy to do though. Thanks -Vincent
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
+1
Thanks -Vincent
On Fri, Sep 30, 2011 at 9:56 AM, Vincent Massol <[email protected]> wrote:
On Sep 29, 2011, at 3:14 AM, Sergiu Dumitriu wrote:
On 09/27/2011 09:55 AM, Denis Gervalle wrote:
On Tue, Sep 27, 2011 at 13:58, Vincent Massol<[email protected]> wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
I know this will be another thread, but why not keep legacy and have a build without legacy stuff. This build could also be a good test that we really do not rely on legacy stuffs.
+1, the legacy module should only be pulled in during releases. The snapshots should be built without them, and the ci tests should be run on a legacy-free build
Well ideally we would need to verify that legacy modules continue to work. So ideally we would special functional tests for legacy modules too with pages using old stuff to make sure they still work. Not very easy to do though.
There is unit tests in legacy for most bridged stuff and it's packaged in XE during integration test but there is probably some missing covering on some parts yes.
Thanks -Vincent
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
+1
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 Thanks, Marius On Tue, Sep 27, 2011 at 2:58 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 09/27/2011 07:58 AM, Vincent Massol wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
+1. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Result: 5 +1, no 0, no -1 The vote is passed, I'm documenting it. Thanks -Vincent On Sep 27, 2011, at 1:58 PM, Vincent Massol wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
Thanks -Vincent
On Sep 30, 2011, at 9:57 AM, Vincent Massol wrote:
Result: 5 +1, no 0, no -1
The vote is passed, I'm documenting it.
Documented here: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDeprecat... Thanks -Vincent
Thanks -Vincent
On Sep 27, 2011, at 1:58 PM, Vincent Massol wrote:
Hi devs,
I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise).
The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module.
My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module.
Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step.
It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so
Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it).
Here's my +1 to follow this practice across our code base and to document it on xwiki.org
Thanks -Vincent
participants (5)
-
Denis Gervalle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol