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. 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
