[xwiki-devs] [PROPOSAL] Determine that it's a new or out of sync instance
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
On Fri, Apr 6, 2012 at 10:49 AM, 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"
+1
2) my +1 goes to another table to not mix different subjects
+0 Thanks, Marius
Thanks, -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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). Thus for me there's only 1 "distribution" in the future, it's the EM one. And XE becomes a "Flavor". So when upgrading you use the list of installed extensions to know what to upgrade. 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). 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
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
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). 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
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
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
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
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
participants (5)
-
Denis Gervalle -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol