+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 <[email protected]> wrote: > 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 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
