On Wed, Apr 11, 2012 at 6:52 PM, Denis Gervalle <[email protected]> wrote: > Hi Thomas, > > I am not sure we are going the right way here ! > As far as I know, the difference between XE or XEM distribution are really > small, and does not really implies the XAR that should be finally
They are not that small actually right now: in XEM you have appmanager, wikimanager and workspacesmanager plus some custom pages added to XE xar. > installed. So the information you propose to store are not so pertinent > IMO. Moreover, the war may be expanded and some of its jar replaced, which > may change its behavior a lot, while the information you store in the > property file are left untouched. > > Currently we may prevent installing a XAR incompatible with the current > core, just by using dependency, and this works without any additional > information about the deployed war. What you want to introduce is the > reverse, and even if I understand your goal, I do not like much this > bilateral dependency. > > If, what you target is to facilitate the upgrade, I would prefer to see a > new feature of EM, that would check for new version of an installed XAR, > and if the new version is installable (its dependencies could be > satisfied), have a proposal for an upgrade. So, upgrading some jars, would > trigger new proposal to upgrade xar, and this would work as well with the > deployment of an upgraded distribution. Adding an UpgradePlanJob to check for new compatible versions of various installed extensions is obviously planned but this proposal is not about that. This is not a system to upgrade all installed extensions, this is a system to know that there is tasks left to do to finish a proper install or upgrade of a distribution and propose to automatically do theses required tasks or at least indicate what the user need to do when it can't be done automatically. There is the need to install some specific extensions like the corresponding standard XAR yes (and the plan is not to upgrade all installed extensions) but not just that, we will want to check the configuration and report what seems wrong (wrong database rights, persistent directory same as temporary directory, etc...) and later even setup the database or any other task that the user has to do when installing XWiki. Upgrade is one thing but if the xar hasn't been installed as an extension you are not going to upgrade much so the main target in this proposal is actually the install step. We could decide that we don't want any specific distribution upgrade UI and just let the user go to EM UI and upgrade the distribution xar among other extensions but I don't find it very friendly. Since this is needed in install I tough it would be nice to do the same thing for upgrade too (at upgrade too you potentially have other things to check than upgrading some extensions, new required property not properly set etc...). But then you need to know when to display this general upgrade Ui and you are not going to display it each time any extension has available updates so you need to differentiate what's actually required for a distribution upgrade and what is just something that can be left to standard EM UI. There is always the risk that the current xar based UI is broken with a new version of the war (would not be the first time) while a template based upgrade UI which would always be in sync with the war since it comes with it is safer. Another issue if that checking for available new versions of installed extensions can be pretty expensive so either we block the startup a long time or we let the user do whatever he want in old version of the UI until we are ready to tell him some extension actually need to be upgraded in order to have the XWiki instance in a proper state. > > Regarding the initial setup, I see no real difficulties when a database is > empty, to propose the installation of the latest compatible version of some > distribution XAR. The only thing we need is to know is what is a > distribution XAR opposed to other extensions. And, we may imagine that we > had finally only one WAR, and that choosing between XE, XEM or anything is > done later, through this mechanism. So, this has nothing to do with storing > additional information on the FS or in the database. The goal here is to do something in 4.1 with the current multiple distributions we have, I'm not working on a 5.x proposal when we will refactor entirely what we release. If later some information become redundant then good we will simply stop providing then in the released distribution package. A user who is installing XE war will expect that we propose to install corresponding distribution xar. Right now I don't see any way to know what XAR to install when starting XWiki the first time to finish the installation. There is nothing in the existing informations that can help with that. We have the version in version.properties, some core extensions (only coming from commons/rendering/platform or completely external dependencies) and that's all. The distribution war is just an assembly of different things as it should. > > I am currently almost -1 to introduce a mechanism that store somewhat > arbitrary information in a war, and this same information in databases, to > provide an installation/upgrade mechanism. My feeling is that we should > work with the existing dependency mechanism provided by EM, extending it a > little bit. This should be more flexible, solid and less prone to weird > issues. It will also scale more easily, especially when we will reduce our > core war to a minimal extension deployer, since at the end, this will be > all we really need. It's not some configuration file that the user is supposed to setup and in which he can make mistakes. It's stable informations (we pretty much never changes them) which are in the sources or generated at build time for the version for example. Exactly like version.properties which already exists, it's just an extension of this file basically. > > Hope you get my idea. I am available to discuss this more in depth if you > need further clarification. > Thanks, IMO this file does not really force anything on the long run since it's very internal stuff with both the data and the system dealing with theses datas coming with the war. We can remove it or part of it any version we want as soon as we find another way we prefer to provide what's in it or make this information useless (by doing a huge refactoring of what's a XWiki distribution for example). In the meantime it provide very quickly a way to display a handy and safe distribution install/upgrade UI to make sure admins stop importing the distribution xar as plain xar with lots of embedded and hidden extensions and as a bonus a good entry point to start putting other stuff like setup validation check etc. > > On Fri, Apr 6, 2012 at 09:49, Thomas Mortagne > <[email protected]>wrote: > >> Hi dev, >> >> To get a proper setup of installed extensions we want to make sure >> everything is installed trough Extension Manager instead of being >> imported as a plain xar. So the idea come up to finally start the long >> awaited installer/upgrader UI. >> >> First step is to find how to know when to display this UI so here is a >> proposal (ref >> http://dev.xwiki.org/xwiki/bin/view/Design/Installerandupgrader): >> >> = The new informations >> >> * deprecate version.properties for a more complete >> distribution.properties that would contains at least the following >> ** version of the distribution >> ** top extension id of the distribution (to display general >> informations about the distribution). For example in XE it would be >> distribution.id=xwiki-enterprise >> ** name of the distribution (I'm not 100% sure for this one since we >> can find it with the id using Extension Manager but I think it's safer >> in case we don't have access to any repository to display something >> nicer than a technical id). For example for XE it would be >> distribution.name=XWiki Enterprise (who would have guessed :)). >> ** war extension id of the distribution (generate a default id like >> <product-id>-web when none is provided). For example in XE it would be >> distribution.web.id=xwiki-enterprise-web >> ** ui extension id of the distribution (generate a default id like >> <product-id>-ui when none is provided). For example in XE it would be >> distribution.ui.id=xwiki-enterprise-ui >> ** then come custom properties specific to the distribution. For >> example in XE I think we could add commons.version, rendering.version, >> etc. >> >> = The current informations >> >> * store all that in a table of the DB to compare the current with what >> comes with the war. If the DB does not contain anything its a new >> install, if the DB contain something different it's an upgrade (note >> that this also support downgrade or moving from one distribution to >> another like XE -> XEM the same way). The idea is that we store theses >> informations only when the installer/upgrader is fully passed or that >> the user explicitly indicated tat he does not want to install or >> upgrade anything so that if you only did part of it before restoring >> you can come back and continue the install/upgrade process. >> >> = The manager >> >> * introduce a xwiki-platform-distribution to manipulate all that >> >> = Some questions >> >> 1) "distribution" or "product" ? >> 2) reuse the same table where we currently store the DB version ? >> >> I don't want to talk about the installed/upgrader UI itself for now, >> it will be the subject of another mail. I would like to concentrate of >> one step at a time since that's going to be pretty important system. >> >> WDYT ? >> >> The may goal that started this proposal is the installer/upgrader UI >> but those as also very useful for different use case. Some lib could >> want to know the version of platform or commons to choose what to do, >> we will be able to add the id of the distribution itself and the war >> extension as core extension to allow some extension to put it as >> dependency, we will finally display a proper footer without putting >> the distribution name in the XWikiPreferences. >> >> Here is my +1. >> >> 1) my +1 goes to "distribution" >> 2) my +1 goes to another table to not mix different subjects >> >> Thanks, >> -- >> Thomas Mortagne >> _______________________________________________ >> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
