On Wed, Apr 11, 2012 at 3:51 PM, Eduard Moraru <[email protected]> wrote: > Hi Thomas, > > AFAIU, you are proposing a way to identify the currently installed war. > > Once you import a xar, you save the information provided by the war into > the database and this means that the current instance is ready. A new > instance will not have the data in the DB and will be marked as not > initialized. > > At this point, we can propose a default xar to import since we know what > war we have, or we can even install it automatically using the EM and not > the import UI. This can be extended to upgrade/downgrade usecases as well > (though a separate discussion concerns how we differentiate and handle > modified installed artefacts -- customized Pages for ex).
Yes that's pretty much the plan. > > 1) +1 > 2) +0 > > If I understood correctly, here's my +1. > > Thanks, > Eduard > > On Tue, Apr 10, 2012 at 3:46 PM, Thomas Mortagne > <[email protected]>wrote: > >> On Tue, Apr 10, 2012 at 2:00 PM, Vincent Massol <[email protected]> >> wrote: >> > Hi Thomas, >> > >> > On Apr 6, 2012, at 9:49 AM, Thomas Mortagne 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. >> > >> > Cool :) >> > >> >> 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 >> > >> > What is a distribution? From what I understand our idea is to not have >> any distribution by default in the future and instead to start up with a >> minimal runtime having only the Extension Manager (and what it needs to >> work) and then ask the user to pick a "Flavor" (preset of extensions) or >> start with an empty "Flavor" (or hand pick the extensions he'd like to see >> used). >> >> That may be the future plan (even if it has mostly been discussed >> privately or suggested in thread that were about another subject) but >> I doubt we are going to start going this in 4.1, are we ? >> >> > >> > Thus for me there's only 1 "distribution" in the future, it's the EM >> one. And XE becomes a "Flavor". >> >> Only one default diftribution, only one we would distribute ourself. >> But I don't think we want to forbid anyone to build a custom >> distribution like XE and XEM are. >> >> > >> > So when upgrading you use the list of installed extensions to know what >> to upgrade. >> >> Yes when upgrading but this proposal is not only abouot upgrading. >> >> When you install the XE war and start XWiki the first time on an empty >> database you need to install the XE xar for it to be complete. So you >> need to know what xar you need to install. The idea here is that you >> provide information about the distribution so that you know what is >> the standard war and xar corresponding to it. >> >> > >> > Now even if we decide to create a static packaging of extensions and >> make it a distribution (which I don't personally want nor like too much) >> then the distribution would simply mean a list of extensions and their >> versions, which we already have AFAIK. >> > >> > Thus from my POV all that we need to know is: >> > a) list of installed extensions and their versions >> > b) list of core extensions and their versions >> > >> > I'm not sure that we need to have a single version representing a) and >> b). >> >> This proposal has nothing to do with installed extensions, we already >> have a list of installed extensions as you can see in the EM UI. >> >> But it's not that simple for core extensions, we know most of the jars >> because a lot of them come with a maven pom and others are matched >> based on their names and the dependencies of the maven jars. But we >> have abssolutely no idea what is the current war for example as I said >> in my first mail and that's exactly the kind of information that the >> distribution.properties would contain along with its corresponding >> standard UI. >> >> > >> > I cannot comment on the rest of this proposal without discussing this >> first. >> > >> > Thanks >> > -Vincent >> > >> >> ** 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 >> > >> > _______________________________________________ >> > 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 >> > _______________________________________________ > 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
