On Wed, Apr 11, 2012 at 7: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 > 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. I like this idea. We could also trigger the check on specific events (like application start) or even allow the user to trigger the check manually. Thanks, Marius > > 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. > > 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. > > Hope you get my idea. I am available to discuss this more in depth if you > need further clarification. > Thanks, > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
