On Thu, Apr 12, 2012 at 1:59 PM, Vincent Massol <[email protected]> wrote: > > On Apr 12, 2012, at 1:51 PM, Denis Gervalle wrote: > >> On Thu, Apr 12, 2012 at 09:57, Vincent Massol <[email protected]> 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… > > 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.
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. > >> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
