Well, I really like the idea, and agree with you that it would simplify upgrade process. If I may, I would propose XWIKI_HOME as environment variable name, and use it both to store permanent data and configuration (in specific sub-folders for example). If one day xwiki manages to upgrade its configuration files at startup automatically (as is done for database) or whatever, then it will appear logical that this conf is in the permanent directory. By the way xwiki could safely propose new conf files with a name scheme (reference.xwiki.properties, reference.xwiki.cfg ...) and rename them only if they do not already exist, that would simplify users life. This really is close to what does Jenkins, and the data directory is JENKINS_HOME. I think this is because the most important and valuable information about your app in this case, is not what's inside the webapp, but what is inside this data directory. So the concept of HOME is appropriate. I apologize as some things here are a bit off-topic, my main point being that XWIKI_HOME would seem more logical to me, as far as I understood the need (and much nicer than XWIKI_PERMANENT_DATA_DIRECTORY or such :) )
Jeremie. 2012/5/27 Thomas Mortagne <[email protected]>: > On Fri, May 25, 2012 at 7:02 PM, Vincent Massol <[email protected]> wrote: >> >> On May 25, 2012, at 3:45 PM, Sergiu Dumitriu wrote: >> >>> On 05/25/2012 02:16 AM, Vincent Massol wrote: >>>> Hi devs, >>>> >>>> Since I'm working on making XE work in Windows7 I've thought more about >>>> XWiki's install and configuration. Actually this is not a new topic, I >>>> remember starting a discussion about it a few years ago on the devs list >>>> but we didn't act on it so here it comes again ;) >>>> >>>> Rationale >>>> ======== >>>> >>>> The idea is to separate XWiki's binaries from its data. There are several >>>> reasons for wanting this: >>>> >>>> * Some OSes require this and don't allow writing in the binary directory. >>>> Windows 7 for example won't allow writing data in \Program Files. >>>> * It makes upgrading simpler since you don't need to fish for >>>> configuration data and copy them somewhere before unpacking a new >>>> distribution over. Or if you unpack in a new directory you don't need to >>>> copy the data from the old directory to the new one. >>>> * As a consequence of the previous point It allows easier auto upgrades of >>>> XE >>>> * It makes it simpler to know what to backup: all you need to back is the >>>> data directory. >>>> >>>> Proposal >>>> ======= >>>> >>>> This is the simplest I've found (I've imagine a lot of more complex >>>> options which offer other small possibilities but in the end I went for >>>> the simpler one for now). So here goes the process when starting up XE: >>>> >>>> * XE looks for a XWIKI_DATA environment variable and if found it uses it >>>> as its environment.permanentDirectory value >>>> * If not found, XE looks in the user home directory for an XWiki >>>> directory. Now the name of this directory is environment-dependent. On non >>>> windows systems it looks for ".xwiki" directory and on Windows systems it >>>> looks for a "XWiki" directory. >>>> * If not found, then XE stops and prints a message in the console >>>> explaining that it couldn't find the location of the XWiki Data dir with >>>> explanations on how to set it. >>>> >>>> The recommendation is thus that users set the XWIKI_DATA environment >>>> property. >>> >>> I prefer the current way, defining it in xwiki.properties. Changing the way >>> this configuration works is going to add some more headache for upgrades. >> >> err? That cannot work :) >> >> Maybe I wasn't clear: the goal is to move XWiki configuration files in a >> different directory from xwiki's binaries, that includes xwiki.properties of >> course :) > > Yes you were definitely not clear since you only talked about > environment.permanentDirectory. > >> >>> AFAIR, it is possible in the izpack installer to filter a configuration >>> file with values from the environment, or even asked from the user. >>> >>> I don't know how many people know how to define system variables, and even >>> with a tutorial in front it is possible to mess it up. >> >> I've mentioned that this proposal has nothing to with installers. They are >> different and of course users don't need to define any variable when using >> installers. >> >>> Plus, on a web-managed environment, are there ways of defining environment >>> variables without needing restart rights on the servlet container? >> >> You mean in case the servlet container is meant to host several webapps, >> xwiki being only one of them and it's not possible to stop it? >> >> Thanks >> -Vincent >> >>>> Notes: >>>> * At startup XE prints as an INFO log the location of the permanent dir it >>>> is using. >>>> * For the standalone distribution we would set the XWIKI_DATA env variable >>>> in the xwiki start file (start_xwiki.sh and start_xwiki.bat) to point to >>>> the data/ dir in the distribution. >>>> * One aspect that is not covered here yet (the topic for another email): >>>> the installer. I'll prepare another mail for that since it's independent >>>> for me. >>>> >>>> Use cases >>>> ========= >>>> >>>> This allows the following use cases: >>>> >>>> * Make it easy to upgrade XE >>>> * Make it easy to backup XE >>>> * MAke it easy to use an existing XE install but point it to a different >>>> configuration, for testing purposes for ex >>>> * Allow installing XE for all users on a system >>>> * Allow installing XE for my user only >>>> >>>> WDYT? >>>> >>>> Thanks >>>> -Vincent >> _______________________________________________ >> 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
