[Yanel-commits] rev 45976 - public/yanel/trunk/src/realms/yanel-website/content

[michi at wyona.com]

Author: michi
Date: 2009-12-11 15:01:33 +0100 (Fri, 11 Dec 2009)
New Revision: 45976

Modified:
   public/yanel/trunk/src/realms/yanel-website/content/789622e2-f022-446a-84d3-8a2d993b7c0d
Log:
text fixed and link added

Modified: public/yanel/trunk/src/realms/yanel-website/content/789622e2-f022-446a-84d3-8a2d993b7c0d
===================================================================
--- public/yanel/trunk/src/realms/yanel-website/content/789622e2-f022-446a-84d3-8a2d993b7c0d	2009-12-11 13:52:20 UTC (rev 45975)
+++ public/yanel/trunk/src/realms/yanel-website/content/789622e2-f022-446a-84d3-8a2d993b7c0d	2009-12-11 14:01:33 UTC (rev 45976)
@@ -10,7 +10,17 @@
 <p>Yanel should be able to update itself. </p>
 
 <p>Hence there is a resource-type <a href="http://svn.wyona.com/repos/public/yanel/trunk/src/realms/welcome-admin/yanel/resources/update-webapp/resource.xml">&quot;update-webapp&quot;</a> which provides an update-manager.
-The update-manager reads the install.rdf (<code>WEB-INF/classes/install.rdf</code>) of the locally installed/deployed Yanel and gets the update-link (<code>updateURL</code>) from it. The update-link points to an update.rdf file located on the update-server (e.g. <a href="http://www.yanel.org/downloads/update.rdf">http://www.yanel.org/downloads/update.rdf</a>) which describes all the relevant changes and the versions accordingly.</p>
+The update-manager reads the install.rdf (<a href="http://svn.wyona.com/repos/public/yanel/trunk/src/build/install.rdf"><code>WEB-INF/classes/install.rdf</code></a>) of the locally installed/deployed Yanel and gets the update-link (<code>updateURL</code>) from it. The update-link points to an update.rdf file located on the update-server (e.g. <a href="http://www.yanel.org/downloads/update.rdf">http://www.yanel.org/downloads/update.rdf</a>) which describes all the relevant changes and the versions accordingly (Also see <a href="#proposal1">proposal 1</a>).</p>
 
-<p>the update.rdf describes the  updates (version, compatibility, the link where to get the particular update). the update-manager compares the current version with the version provided by the update.rdf and displays all the version which the current yanel could update to. <br/></p><p>the user can choose which version she wants to update to. the update-manager then does a backup of the current yanel [problem1] downloads the war of the update version, merges the changes in the config files [problem2] (which are listed in the install.rdf) into the downloaded update and deploys it. if the user is not happy with the updated version she could revert the update. the update-manager would deploy the backup again.</p><b>problems:</b><ul><li>[problem1] to backup the current version yanel should block all request while backuping tp prevent inconsistency<br/></li><li>[problem2] to allow a merge of the config all config files should be xml rather than property files</li><li>if the updat!
 e would fail and break yanel, the update-manager would not be available anymore to manage the revert. maybe the update-manager should stay in a seperate servlet.</li><li>if the update-manager should handle every servlet container complexity will increase. maybe we should limit it to tomcat which comes with the binary version.</li></ul><b>proposals:<br/></b><ul><li>[proposal1] to provide the updates resp. update.rdf  there should be a realm which contents the updates. this realm would not be included within yanel.<br/></li></ul> <br/></body>
+<p>The update.rdf describes the  updates (version, compatibility, the link where to get the particular update). The update-manager compares the current version (install.rdf) with the version provided by the update.rdf and displays all the version which the current Yanel could update to.</p>
+
+<p>The user can choose which version she wants to update to. the update-manager then does a backup of the current yanel [problem1] downloads the war of the update version, merges the changes in the config files [problem2] (which are listed in the install.rdf) into the downloaded update and deploys it. if the user is not happy with the updated version she could revert the update. the update-manager would deploy the backup again.</p>
+
+
+<b>Problems:</b><ul><li>[problem1] to backup the current version yanel should block all request while backuping tp prevent inconsistency<br/></li><li>[problem2] to allow a merge of the config all config files should be xml rather than property files</li><li>if the update would fail and break yanel, the update-manager would not be available anymore to manage the revert. maybe the update-manager should stay in a seperate servlet.</li><li>if the update-manager should handle every servlet container complexity will increase. maybe we should limit it to tomcat which comes with the binary version.</li></ul>
+
+<a name="proposal1">&#160;</a>
+<b>Proposals:</b>
+<br/>
+<ul><li>[Proposal 1] To provide the updates (including update.rdf) there should be a realm which contains the updates. This realm would not be included within yanel.<br/></li></ul> <br/></body>
 </html>