12 Apr
2012
12 Apr
'12
9:57 a.m.
Hi devs,
In preparation of our Deprecation Day and continuing our vote on the Deprecation strategy
I'd like to propose several rules we need to clarify since we need them and I'd
like to finish documenting our full deprecation strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module for holding legacy
modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside their own
module (for ex in
xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/) because legacy
modules are something we don't want to see as much as possible since we're must
not use them in our code, thus it's logical to park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds to. This means
that the user must have only 1 JAR for a given module: either its legacy version or
it's non-legacy version but should never have both.
* Explanation:
- We need consistency. Right now we have oldcore which acts like this but others don't
and it's complex to explain to users that for some they have to swap them and for
others they have to keep both side by side
- In the very close future, we'll use a lot of Aspects in modules others than
legacy-oldcore, and thus we'll need to apply this strategy anyway.
* Notes:
- Currently, only oldcore acts like this.
- The consequence is that we'll have one legacy module per non legacy modules. Right
now we sometimes have one legacy module for several non legacy modules which we'll
need to fix
Here's my +1 to both.
Thanks
-Vincent
12 Apr
12 Apr
1:51 p.m.
On Thu, Apr 12, 2012 at 09:57, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
In preparation of our Deprecation Day and continuing our vote on the
Deprecation strategy I'd like to propose several rules we need to clarify
since we need them and I'd like to finish documenting our full deprecation
strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module
for holding legacy modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
+1
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside
their own module (for ex in
xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/)
because legacy modules are something we don't want to see as much as
possible since we're must not use them in our code, thus it's logical to
park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds
to. This means that the user must have only 1 JAR for a given module:
either its legacy version or it's non-legacy version but should never have
both.
This make me think that this could cause some difficulties for the EM to
install legacy modules, since it would require the non-legacy one to be
unloaded, or used an override mechanism by ClassLoader, which could lead to
other issues like memory consumption, singleton classloader issue...
I am not really experienced with Aspects, but isn't there a better way to
manager this ? IMO we are loosing in flexibility. Is the benefit of
Aspect outweigh this constrain ?
* Explanation:
- We need consistency. Right now we have oldcore which acts like this but
others don't and it's complex to explain to users that for some they have
to swap them and for others they have to keep both side by side
- In the very close future, we'll use a lot of Aspects in modules others
than legacy-oldcore, and thus we'll need to apply this strategy anyway.
* Notes:
- Currently, only oldcore acts like this.
- The consequence is that we'll have one legacy module per non legacy
modules. Right now we sometimes have one legacy module for several non
legacy modules which we'll need to fix
Here's my +1 to both.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
1:59 p.m.
On Apr 12, 2012, at 1:51 PM, Denis Gervalle wrote:
On Thu, Apr 12, 2012 at 09:57, Vincent Massol
<vincent(a)massol.net> wrote:
Thomas has introduced a notion of 'alias' in the EM but not sure if it solves
this. I'll let him answer when he's back.
FYI we're already using it in our pom.xml. For ex for oldcore we have (don't ask
me what the comment means because I don't really understand it ;)):
<!-- The features provided by this module so that it's found when resolving
extension that pretty much never depend on this one -->
<xwiki.extension.features>org.xwiki.platform:xwiki-platform-oldcore,com.xpn.xwiki.platform:xwiki-core</xwiki.extension.features>
I think this means that org.xwiki.platform:xwiki-platform-oldcore and
com.xpn.xwiki.platform:xwiki-core are aliases of xwiki-platform-legacy-oldcore. But
I'm not sure how this is used by the EM.
Hi devs,
In preparation of our Deprecation Day and continuing our vote on the
Deprecation strategy I'd like to propose several rules we need to clarify
since we need them and I'd like to finish documenting our full deprecation
strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module
for holding legacy modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
+1
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside
their own module (for ex in
xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/)
because legacy modules are something we don't want to see as much as
possible since we're must not use them in our code, thus it's logical to
park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds
to. This means that the user must have only 1 JAR for a given module:
either its legacy version or it's non-legacy version but should never have
both.
This make me think that this could cause some difficulties for the EM to
install legacy modules, since it would require the non-legacy one to be
unloaded, or used an override mechanism by ClassLoader, which could lead to
other issues like memory consumption, singleton classloader issue… I am not really experienced with Aspects, but
isn't there a better way to
manager this ?
No
IMO we are loosing in flexibility. Is the benefit of
Aspect outweigh this constrain ?
Yes definitely by far.
IMO it's perfectly fine to not support installing legacy modules using the EM since
it's a very special use case. If we can support it then all the best, if we cannot
then so be it.
Thanks
-Vincent
> * Explanation:
> - We need consistency. Right now we have oldcore which acts like this but
> others don't and it's complex to explain to users that for some they have
> to swap them and for others they have to keep both side by side
> - In the very close future, we'll use a lot of Aspects in modules others
> than legacy-oldcore, and thus we'll need to apply this strategy anyway.
>
> * Notes:
> - Currently, only oldcore acts like this.
> - The consequence is that we'll have one legacy module per non legacy
> modules. Right now we sometimes have one legacy module for several non
> legacy modules which we'll need to fix
>
> Here's my +1 to both.
>
> Thanks
> -Vincent
18 Apr
18 Apr
10:39 a.m.
On Thu, Apr 12, 2012 at 1:59 PM, Vincent Massol <vincent(a)massol.net> wrote:
--
Thomas Mortagne
On Apr 12, 2012, at 1:51 PM, Denis Gervalle wrote:
The issue is not here. No extension depends on legacy module so when
you install some extension it's usually not going to install the
legacy module. If you have a more recent version of this dependency
and moved some API used by the extension the result will be that your
extension will not work anymore.
Another issue is with core extension, if you have the proper module as
core extension (like oldcore for example) you can't replace it with
the legacy module using Extension Manager since EM cannot remove a
core extension so at best you would have both module in the
classloader which would only lead to issues.
So I agree with Denis that releasing a XE without any legacy module by
default is not that simple.
On Thu, Apr 12, 2012 at 09:57, Vincent Massol
<vincent(a)massol.net> wrote:
Thomas has introduced a notion of 'alias' in the EM but not sure if it solves
this. I'll let him answer when he's back.
FYI we're already using it in our pom.xml. For ex for oldcore we have (don't ask
me what the comment means because I don't really understand it ;)):
<!-- The features provided by this module so that it's found when resolving
extension that pretty much never depend on this one -->
<xwiki.extension.features>org.xwiki.platform:xwiki-platform-oldcore,com.xpn.xwiki.platform:xwiki-core</xwiki.extension.features>
I think this means that org.xwiki.platform:xwiki-platform-oldcore and
com.xpn.xwiki.platform:xwiki-core are aliases of xwiki-platform-legacy-oldcore. But
I'm not sure how this is used by the EM. Hi devs,
In preparation of our Deprecation Day and continuing our vote on the
Deprecation strategy I'd like to propose several rules we need to clarify
since we need them and I'd like to finish documenting our full deprecation
strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module
for holding legacy modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
+1
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside
their own module (for ex in
xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/)
because legacy modules are something we don't want to see as much as
possible since we're must not use them in our code, thus it's logical to
park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds
to. This means that the user must have only 1 JAR for a given module:
either its legacy version or it's non-legacy version but should never have
both.
This make me think that this could cause some difficulties for the EM to
install legacy modules, since it would require the non-legacy one to be
unloaded, or used an override mechanism by ClassLoader, which could lead to
other issues like memory consumption, singleton classloader issue… I am not really experienced with Aspects, but
isn't there a better way to
manager this ?
No
IMO we are loosing in flexibility. Is the benefit
of
Aspect outweigh this constrain ?
Yes definitely by far.
IMO it's perfectly fine to not support installing legacy modules using the EM since
it's a very special use case. If we can support it then all the best, if we cannot
then so be it.
Thanks
-Vincent
> * Explanation:
> - We need consistency. Right now we have oldcore which acts like this but
> others don't and it's complex to explain to users that for some they have
> to swap them and for others they have to keep both side by side
> - In the very close future, we'll use a lot of Aspects in modules others
> than legacy-oldcore, and thus we'll need to apply this strategy anyway.
>
> * Notes:
> - Currently, only oldcore acts like this.
> - The consequence is that we'll have one legacy module per non legacy
> modules. Right now we sometimes have one legacy module for several non
> legacy modules which we'll need to fix
>
> Here's my +1 to both.
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
26 Apr
26 Apr
6:40 p.m.
+1 for now since we ship legacy module in XE but at some point we will
have to find a way to fix the issue I described if we start having not
bundled legacy modules
On Wed, Apr 18, 2012 at 10:39 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Thu, Apr 12, 2012 at 1:59 PM, Vincent Massol
<vincent(a)massol.net> wrote:
--
Thomas Mortagne
--
Thomas Mortagne
On Apr 12, 2012, at 1:51 PM, Denis Gervalle wrote:
The issue is not here. No extension depends on legacy module so when
you install some extension it's usually not going to install the
legacy module. If you have a more recent version of this dependency
and moved some API used by the extension the result will be that your
extension will not work anymore.
Another issue is with core extension, if you have the proper module as
core extension (like oldcore for example) you can't replace it with
the legacy module using Extension Manager since EM cannot remove a
core extension so at best you would have both module in the
classloader which would only lead to issues.
So I agree with Denis that releasing a XE without any legacy module by
default is not that simple.
On Thu, Apr 12, 2012 at 09:57, Vincent Massol
<vincent(a)massol.net> wrote:
Thomas has introduced a notion of 'alias' in the EM but not sure if it solves
this. I'll let him answer when he's back.
FYI we're already using it in our pom.xml. For ex for oldcore we have (don't ask
me what the comment means because I don't really understand it ;)):
<!-- The features provided by this module so that it's found when resolving
extension that pretty much never depend on this one -->
<xwiki.extension.features>org.xwiki.platform:xwiki-platform-oldcore,com.xpn.xwiki.platform:xwiki-core</xwiki.extension.features>
I think this means that org.xwiki.platform:xwiki-platform-oldcore and
com.xpn.xwiki.platform:xwiki-core are aliases of xwiki-platform-legacy-oldcore. But
I'm not sure how this is used by the EM. Hi devs,
In preparation of our Deprecation Day and continuing our vote on the
Deprecation strategy I'd like to propose several rules we need to clarify
since we need them and I'd like to finish documenting our full deprecation
strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module
for holding legacy modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
+1
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside
their own module (for ex in
xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/)
because legacy modules are something we don't want to see as much as
possible since we're must not use them in our code, thus it's logical to
park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds
to. This means that the user must have only 1 JAR for a given module:
either its legacy version or it's non-legacy version but should never have
both.
This make me think that this could cause some difficulties for the EM to
install legacy modules, since it would require the non-legacy one to be
unloaded, or used an override mechanism by ClassLoader, which could lead to
other issues like memory consumption, singleton classloader issue… I am not really experienced with Aspects, but
isn't there a better way to
manager this ?
No
IMO we are loosing in flexibility. Is the benefit
of
Aspect outweigh this constrain ?
Yes definitely by far.
IMO it's perfectly fine to not support installing legacy modules using the EM since
it's a very special use case. If we can support it then all the best, if we cannot
then so be it.
Thanks
-Vincent
> * Explanation:
> - We need consistency. Right now we have oldcore which acts like this but
> others don't and it's complex to explain to users that for some they have
> to swap them and for others they have to keep both side by side
> - In the very close future, we'll use a lot of Aspects in modules others
> than legacy-oldcore, and thus we'll need to apply this strategy anyway.
>
> * Notes:
> - Currently, only oldcore acts like this.
> - The consequence is that we'll have one legacy module per non legacy
> modules. Right now we sometimes have one legacy module for several non
> legacy modules which we'll need to fix
>
> Here's my +1 to both.
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12 Apr
12 Apr
2:15 p.m.
On Apr 12, 2012, at 9:57 AM, Vincent Massol wrote:
Hi devs,
In preparation of our Deprecation Day and continuing our vote on the Deprecation strategy
I'd like to propose several rules we need to clarify since we need them and I'd
like to finish documenting our full deprecation strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module for holding
legacy modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside their own
module (for ex in
xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/) because legacy
modules are something we don't want to see as much as possible since we're must
not use them in our code, thus it's logical to park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds to. This means
that the user must have only 1 JAR for a given module: either its legacy version or
it's non-legacy version but should never have both.
* Explanation:
- We need consistency. Right now we have oldcore which acts like this but others
don't and it's complex to explain to users that for some they have to swap them
and for others they have to keep both side by side
- In the very close future, we'll use a lot of Aspects in modules others than
legacy-oldcore, and thus we'll need to apply this strategy anyway.
* Notes:
- Currently, only oldcore acts like this.
- The consequence is that we'll have one legacy module per non legacy modules. Right
now we sometimes have one legacy module for several non legacy modules which we'll
need to fix
Here's my +1 to both.
We also need some way to know that the move of some deprecated API to legacy works. So I
think we need Rule 3.
Rule 3: Ensure that the moved out code works
====================================
* Proposal:
- Add a unit test in the legacy module to prove that the moved code still works
* Notes:
- Usually this simply means moving the existing unit tests to the legacy module too or
duplicating it and use the deprecated classes in the legacy version
Here's my +1
Thanks
-Vincent
Thanks
-Vincent
13 Apr
13 Apr
1:01 p.m.
FYI I've now validated those 3 rules by moving out the deprecated methods from
ComponentManager into legacy modules (http://jira.xwiki.org/jira/browse/XCOMMONS-150)
If you wish to see what's involved:
*
https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-core/xwiki…
* https://github.com/xwiki/xwiki-enterprise/blob/master/xwiki-enterprise-web/…
If we agree with those 3 rules we're ready for the Deprecation day :)
Please vote.
Thanks
-Vincent
On Apr 12, 2012, at 2:15 PM, Vincent Massol wrote:
On Apr 12, 2012, at 9:57 AM, Vincent Massol wrote:
Hi devs,
In preparation of our Deprecation Day and continuing our vote on the Deprecation strategy
I'd like to propose several rules we need to clarify since we need them and I'd
like to finish documenting our full deprecation strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module for holding
legacy modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside their own
module (for ex in
xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/) because legacy
modules are something we don't want to see as much as possible since we're must
not use them in our code, thus it's logical to park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds to. This means
that the user must have only 1 JAR for a given module: either its legacy version or
it's non-legacy version but should never have both.
* Explanation:
- We need consistency. Right now we have oldcore which acts like this but others
don't and it's complex to explain to users that for some they have to swap them
and for others they have to keep both side by side
- In the very close future, we'll use a lot of Aspects in modules others than
legacy-oldcore, and thus we'll need to apply this strategy anyway.
* Notes:
- Currently, only oldcore acts like this.
- The consequence is that we'll have one legacy module per non legacy modules. Right
now we sometimes have one legacy module for several non legacy modules which we'll
need to fix
Here's my +1 to both.
We also need some way to know that the move of some deprecated API to legacy works. So I
think we need Rule 3.
Rule 3: Ensure that the moved out code works
====================================
* Proposal:
- Add a unit test in the legacy module to prove that the moved code still works
* Notes:
- Usually this simply means moving the existing unit tests to the legacy module too or
duplicating it and use the deprecated classes in the legacy version
Here's my +1
Thanks
-Vincent
Thanks
-Vincent
26 Apr
26 Apr
6:53 p.m.
I've documented this at
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwar…
Thanks
-Vincent
On Apr 12, 2012, at 9:57 AM, Vincent Massol wrote:
Hi devs,
In preparation of our Deprecation Day and continuing our vote on the Deprecation strategy
I'd like to propose several rules we need to clarify since we need them and I'd
like to finish documenting our full deprecation strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module for holding
legacy modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside their own
module (for ex in
xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/) because legacy
modules are something we don't want to see as much as possible since we're must
not use them in our code, thus it's logical to park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds to. This means
that the user must have only 1 JAR for a given module: either its legacy version or
it's non-legacy version but should never have both.
* Explanation:
- We need consistency. Right now we have oldcore which acts like this but others
don't and it's complex to explain to users that for some they have to swap them
and for others they have to keep both side by side
- In the very close future, we'll use a lot of Aspects in modules others than
legacy-oldcore, and thus we'll need to apply this strategy anyway.
* Notes:
- Currently, only oldcore acts like this.
- The consequence is that we'll have one legacy module per non legacy modules. Right
now we sometimes have one legacy module for several non legacy modules which we'll
need to fix
Here's my +1 to both.
Thanks
-Vincent
4526
days inactive
4540
days old
7 comments
3 participants
participants (3)
-
Denis Gervalle -
Thomas Mortagne -
Vincent Massol