1 Jun
2012
1 Jun
'12
3:30 p.m.
Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for holding
(permanent) data and allow various configurations for our distributions.
* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg,
xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/,
jetty log files
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7 which require a
total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can continue since
I'm currently blocked.
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as
now)
** If no environment.permanentDirectory exists, then use the temporary directory (same as
now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add support for a
Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and
xwiki.data.dir=[homedir]/data
* environment.permanentDirectory is not defined in xwiki.properties
UC2:
* user unzips new version in another directory and copy the old data and config
directories over
* Note that this use case is not really a valid one since the standalone zip is not meant
to be a production zip at the moment
UC3:
* user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to
set environment.permanentDirectory (same as now)
* however the recommendation is for the user to put it's XWiki config dir and data dir
somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system properties
in his startup/stop scripts, thus making it easy for UC4
UC4:
* users replaces the older WAR with the new WAR and if he has applied the recommendation
from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file
to set environment.permanentDirectory
WDYT?
Thanks
-Vincent
1 Jun
1 Jun
6:16 p.m.
On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for
holding (permanent) data and allow various configurations for our
distributions.
* Config dir is where xwiki configuration files is located. Examples:
xwiki.cfg, xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/,
extension/ lucene/, jetty log files
Should'nt we also consider a separate cache directory for stuffs like
lucene which does not really require backup, and a log directory for logs
file. This would better fit the FHS which concider /etc, /var/lib,
/var/cache and /var/log. We could of course have defaults to the data
directory for these unless specifically defined.
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7
which require a total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can
continue since I'm currently blocked.
You just not describe what you will do in the installer for Windows 7 ?
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment
Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment
Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in
xwiki.properties (same as now)
** If no environment.permanentDirectory exists, then use the temporary
directory (same as now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add
support for a Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config
and xwiki.data.dir=[homedir]/data
* environment.permanentDirectory is not defined in xwiki.properties
UC2:
* user unzips new version in another directory and copy the old data and
config directories over
* Note that this use case is not really a valid one since the standalone
zip is not meant to be a production zip at the moment
UC3:
* user deploys war in container's webapps dir and edits
WEB-INF/xwiki.properties to set environment.permanentDirectory (same as
now)
* however the recommendation is for the user to put it's XWiki config dir
and data dir somewhere on his system and use the xwiki.config.dir and
xwiki.data.dir system properties in his startup/stop scripts, thus making
it easy for UC4
UC4:
* users replaces the older WAR with the new WAR and if he has applied the
recommendation from UC3 that's all he has to do. Otherwise he needs to edit
the xwiki.properties file to set environment.permanentDirectory
WDYT?
This sounds good. I would suggest that the debian package be updated to
better respect the FHS, using /etc and /var appropriately.
So +1 for this with a strong filling we should extend it more to allow full
compliance with FHS.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
2 Jun
2 Jun
4:03 p.m.
On Fri, Jun 1, 2012 at 6:16 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I don't understand what you mean, the debian package already use /etc and /var.
Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for
holding (permanent) data and allow various configurations for our
distributions.
* Config dir is where xwiki configuration files is located. Examples:
xwiki.cfg, xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/,
extension/ lucene/, jetty log files
Should'nt we also consider a separate cache directory for stuffs like
lucene which does not really require backup, and a log directory for logs
file. This would better fit the FHS which concider /etc, /var/lib,
/var/cache and /var/log. We could of course have defaults to the data
directory for these unless specifically defined.
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7
which require a total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can
continue since I'm currently blocked.
You just not describe what you will do in the installer for Windows 7 ?
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment
Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment
Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in
xwiki.properties (same as now)
** If no environment.permanentDirectory exists, then use the temporary
directory (same as now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add
support for a Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config
and xwiki.data.dir=[homedir]/data
* environment.permanentDirectory is not defined in xwiki.properties
UC2:
* user unzips new version in another directory and copy the old data and
config directories over
* Note that this use case is not really a valid one since the standalone
zip is not meant to be a production zip at the moment
UC3:
* user deploys war in container's webapps dir and edits
WEB-INF/xwiki.properties to set environment.permanentDirectory (same as
now)
* however the recommendation is for the user to put it's XWiki config dir
and data dir somewhere on his system and use the xwiki.config.dir and
xwiki.data.dir system properties in his startup/stop scripts, thus making
it easy for UC4
UC4:
* users replaces the older WAR with the new WAR and if he has applied the
recommendation from UC3 that's all he has to do. Otherwise he needs to edit
the xwiki.properties file to set environment.permanentDirectory
WDYT?
This sounds good. I would suggest that the debian package be updated to
better respect the FHS, using /etc and /var appropriately. So +1 for this with a strong filling we should extend
it more to allow full
compliance with FHS.
--
Thomas Mortagne
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4 Jun
4 Jun
10:04 a.m.
On Jun 1, 2012, at 6:16 PM, Denis Gervalle wrote:
Indeed I wanted to separate manual installs from Installers. Ok so here's what I plan
to do short-term in the Windows7 installer for 4.1RC1 (to be improved later):
* Only handle data dir
* Generate 2 version of start/stop shell scripts with one version being for Windows7 and
the rest for the other OSes. The Windows7 version will have the system property
xwiki.data.dir set to %PROGRAMDATA%\XWiki\data (leaving %PROGRAMDATA%\XWiki\config
available for later on)
* Don't set environment.permanentDirectory (again 2 set of files for xwiki.properties,
one for Windows7 and the rest for other OSes)
* Modify Environment module implementation to default to the system property when no
environment.permanentDirectory is set
* Copy HSQLDB data to %PROGRAMDATA%\XWiki\data\database
Thanks
-Vincent
On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Yes we could. I agree that we would need those to be optional and default to the data dir
to make it simple.
Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for
holding (permanent) data and allow various configurations for our
distributions.
* Config dir is where xwiki configuration files is located. Examples:
xwiki.cfg, xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/,
extension/ lucene/, jetty log files
Should'nt we also consider a separate cache directory for stuffs like
lucene which does not really require backup, and a log directory for logs
file. This would better fit the FHS which concider /etc, /var/lib,
/var/cache and /var/log. We could of course have defaults to the data
directory for these unless specifically defined. Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7
which require a total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can
continue since I'm currently blocked.
You just not describe what you will do in the installer for Windows 7 ? Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment
Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment
Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in
xwiki.properties (same as now)
** If no environment.permanentDirectory exists, then use the temporary
directory (same as now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add
support for a Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config
and xwiki.data.dir=[homedir]/data
* environment.permanentDirectory is not defined in xwiki.properties
UC2:
* user unzips new version in another directory and copy the old data and
config directories over
* Note that this use case is not really a valid one since the standalone
zip is not meant to be a production zip at the moment
UC3:
* user deploys war in container's webapps dir and edits
WEB-INF/xwiki.properties to set environment.permanentDirectory (same as
now)
* however the recommendation is for the user to put it's XWiki config dir
and data dir somewhere on his system and use the xwiki.config.dir and
xwiki.data.dir system properties in his startup/stop scripts, thus making
it easy for UC4
UC4:
* users replaces the older WAR with the new WAR and if he has applied the
recommendation from UC3 that's all he has to do. Otherwise he needs to edit
the xwiki.properties file to set environment.permanentDirectory
WDYT?
This sounds good. I would suggest that the debian package be updated to
better respect the FHS, using /etc and /var appropriately.
So +1 for this with a strong filling we should extend it more to allow full
compliance with FHS.
>
> Thanks
> -Vincent
2 Jun
2 Jun
4:06 p.m.
On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for holding
(permanent) data and allow various configurations for our distributions.
* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg,
xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/,
jetty log files
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7 which require a
total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can continue since
I'm currently blocked.
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as
now)
** If no environment.permanentDirectory exists, then use the temporary directory (same as
now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add support for a
Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and
xwiki.data.dir=[homedir]/data
There is something missing here. XWiki is not going to find anything
in [homedir]/config obviously when starting so how does he knows about
proper hsqldb configuration for example ? Is the configuration copied
from the war the first time it starts ?
* environment.permanentDirectory is not defined in
xwiki.properties
UC2:
* user unzips new version in another directory and copy the old data and config
directories over
* Note that this use case is not really a valid one since the standalone zip is not meant
to be a production zip at the moment
UC3:
* user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to
set environment.permanentDirectory (same as now)
* however the recommendation is for the user to put it's XWiki config dir and data
dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system
properties in his startup/stop scripts, thus making it easy for UC4
UC4:
* users replaces the older WAR with the new WAR and if he has applied the recommendation
from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file
to set environment.permanentDirectory
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
4 Jun
4 Jun
10:06 a.m.
On Jun 2, 2012, at 4:06 PM, Thomas Mortagne wrote:
On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol
<vincent(a)massol.net> wrote:
The zip contains everything. Its structure would be:
[homedir]/
|_ data/
|_ config/
|_ jetty/
|_ webapps/
|_ start_xwiki.sh
|_ …
In the start/stop shell scripts, we will have: -Dxwiki.data.dir=data and
-Dxwiki.config.dir=config
Hope it's more clear :)
Thanks
-Vincent
Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for holding
(permanent) data and allow various configurations for our distributions.
* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg,
xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/,
jetty log files
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7 which require a
total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can continue since
I'm currently blocked.
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as
now)
** If no environment.permanentDirectory exists, then use the temporary directory (same as
now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add support for a
Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and
xwiki.data.dir=[homedir]/data
There is something missing here. XWiki is not going to find anything
in [homedir]/config obviously when starting so how does he knows about
proper hsqldb configuration for example ? Is the configuration copied
from the war the first time it starts ? > * environment.permanentDirectory is not defined in
xwiki.properties
>
> UC2:
> * user unzips new version in another directory and copy the old data and config
directories over
> * Note that this use case is not really a valid one since the standalone zip is not
meant to be a production zip at the moment
>
> UC3:
> * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties
to set environment.permanentDirectory (same as now)
> * however the recommendation is for the user to put it's XWiki config dir and
data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system
properties in his startup/stop scripts, thus making it easy for UC4
>
> UC4:
> * users replaces the older WAR with the new WAR and if he has applied the
recommendation from UC3 that's all he has to do. Otherwise he needs to edit the
xwiki.properties file to set environment.permanentDirectory
>
> WDYT?
>
> Thanks
> -Vincent
10:41 a.m.
On Mon, Jun 4, 2012 at 10:06 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Jun 2, 2012, at 4:06 PM, Thomas Mortagne wrote:
Yes, was actually understanding [homedir] as the user home directory
(like the HOME env var on unix systems, not sure about its names on
Windows).
On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol
<vincent(a)massol.net> wrote:
The zip contains everything. Its structure would be:
[homedir]/
|_ data/
|_ config/
|_ jetty/
|_ webapps/
|_ start_xwiki.sh
|_ …
In the start/stop shell scripts, we will have: -Dxwiki.data.dir=data and
-Dxwiki.config.dir=config
Hope it's more clear :) Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for holding
(permanent) data and allow various configurations for our distributions.
* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg,
xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/,
jetty log files
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7 which require a
total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can continue since
I'm currently blocked.
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as
now)
** If no environment.permanentDirectory exists, then use the temporary directory (same as
now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add support for a
Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and
xwiki.data.dir=[homedir]/data
There is something missing here. XWiki is not going to find anything
in [homedir]/config obviously when starting so how does he knows about
proper hsqldb configuration for example ? Is the configuration copied
from the war the first time it starts ?
Thanks
-Vincent
--
Thomas Mortagne
> * environment.permanentDirectory is not
defined in xwiki.properties
>
> UC2:
> * user unzips new version in another directory and copy the old data and config
directories over
> * Note that this use case is not really a valid one since the standalone zip is not
meant to be a production zip at the moment
>
> UC3:
> * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties
to set environment.permanentDirectory (same as now)
> * however the recommendation is for the user to put it's XWiki config dir and
data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system
properties in his startup/stop scripts, thus making it easy for UC4
>
> UC4:
> * users replaces the older WAR with the new WAR and if he has applied the
recommendation from UC3 that's all he has to do. Otherwise he needs to edit the
xwiki.properties file to set environment.permanentDirectory
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:23 a.m.
+1 btw
On Mon, Jun 4, 2012 at 10:41 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Mon, Jun 4, 2012 at 10:06 AM, Vincent Massol
<vincent(a)massol.net> wrote:
--
Thomas Mortagne
On Jun 2, 2012, at 4:06 PM, Thomas Mortagne wrote:
Yes, was actually understanding [homedir] as the user home directory
(like the HOME env var on unix systems, not sure about its names on
Windows).
On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol
<vincent(a)massol.net> wrote:
The zip contains everything. Its structure would be:
[homedir]/
|_ data/
|_ config/
|_ jetty/
|_ webapps/
|_ start_xwiki.sh
|_ …
In the start/stop shell scripts, we will have: -Dxwiki.data.dir=data and
-Dxwiki.config.dir=config
Hope it's more clear :) Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for holding
(permanent) data and allow various configurations for our distributions.
* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg,
xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/,
jetty log files
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7 which require a
total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can continue since
I'm currently blocked.
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as
now)
** If no environment.permanentDirectory exists, then use the temporary directory (same as
now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add support for a
Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and
xwiki.data.dir=[homedir]/data
There is something missing here. XWiki is not going to find anything
in [homedir]/config obviously when starting so how does he knows about
proper hsqldb configuration for example ? Is the configuration copied
from the war the first time it starts ?
Thanks
-Vincent
--
Thomas Mortagne > * environment.permanentDirectory is not
defined in xwiki.properties
>
> UC2:
> * user unzips new version in another directory and copy the old data and config
directories over
> * Note that this use case is not really a valid one since the standalone zip is not
meant to be a production zip at the moment
>
> UC3:
> * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties
to set environment.permanentDirectory (same as now)
> * however the recommendation is for the user to put it's XWiki config dir and
data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system
properties in his startup/stop scripts, thus making it easy for UC4
>
> UC4:
> * users replaces the older WAR with the new WAR and if he has applied the
recommendation from UC3 that's all he has to do. Otherwise he needs to edit the
xwiki.properties file to set environment.permanentDirectory
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
11:10 a.m.
+1
Best Regards,
/Andreas
On 2012-06-01 15:30, Vincent Massol wrote:
Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for holding
(permanent) data and allow various configurations for our distributions.
* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg,
xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/,
jetty log files
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7 which require a
total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can continue since
I'm currently blocked.
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as
now)
** If no environment.permanentDirectory exists, then use the temporary directory (same as
now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add support for a
Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and
xwiki.data.dir=[homedir]/data
* environment.permanentDirectory is not defined in xwiki.properties
UC2:
* user unzips new version in another directory and copy the old data and config
directories over
* Note that this use case is not really a valid one since the standalone zip is not meant
to be a production zip at the moment
UC3:
* user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to
set environment.permanentDirectory (same as now)
* however the recommendation is for the user to put it's XWiki config dir and data
dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system
properties in his startup/stop scripts, thus making it easy for UC4
UC4:
* users replaces the older WAR with the new WAR and if he has applied the recommendation
from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file
to set environment.permanentDirectory
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:50 a.m.
+1
Thanks,
Marius
On Fri, Jun 1, 2012 at 4:30 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
This proposal is a restart of the thread I've sent, entitled "[Proposal]
XWiki's Permanent Directory Strategy for Installations" in which I wasn't
clear.
Executive Summary
================
Define 2 XWiki directories; one for holding configuration data and one for holding
(permanent) data and allow various configurations for our distributions.
* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg,
xwiki.properties, hibernate.cfg.xml
* Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/,
jetty log files
Rationale
========
This proposal below tries to answer the following general use cases:
* Ability to easily backup an XWiki install
* Ability to easily upgrade an XWiki install
* Ability to install XWiki on various OSes, including OSes like Windows 7 which require a
total separation of readonly binaries and generated data
* Ability to have several instances of XWiki on the same machine
Note that I'm sending this email since I'm currently working on making our
installer work on Windows 7 and I need an agreement on this before I can continue since
I'm currently blocked.
Use Cases
=========
The proposal below should allow the following use cases easily:
UC1: use the standalone zip distribution
UC2: upgrade a standalone zip distribution install
UC3: Use the WAR production distribution
UC4: Upgrade an existing WAR distribution
Short Term Proposal
=================
* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir
* Use the following algorithm for resolving the Config dir (in Environment Module):
** Check if system property xwiki.config.dir is set, if so, use it
** Otherwise default to the WEB-INF directory (same as now)
* Use the following algorithm for resolving the Data dir (in Environment Module):
** Check if system property xwiki.data.dir is set, if so, use it
** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as
now)
** If no environment.permanentDirectory exists, then use the temporary directory (same as
now)
* Don't provide a default value for environment.permanentDirectory in
xwiki.properties
* Note that we probably need to modify a bit Environment module to add support for a
Configuration directory (not sure yet about this need).
Use Cases Walkthrough
===================
UC1:
* user unzips, that's all
* in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and
xwiki.data.dir=[homedir]/data
* environment.permanentDirectory is not defined in xwiki.properties
UC2:
* user unzips new version in another directory and copy the old data and config
directories over
* Note that this use case is not really a valid one since the standalone zip is not meant
to be a production zip at the moment
UC3:
* user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to
set environment.permanentDirectory (same as now)
* however the recommendation is for the user to put it's XWiki config dir and data
dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system
properties in his startup/stop scripts, thus making it easy for UC4
UC4:
* users replaces the older WAR with the new WAR and if he has applied the recommendation
from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file
to set environment.permanentDirectory
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4540
days inactive
4543
days old
9 comments
5 participants
participants (5)
-
Andreas Jonsson -
Denis Gervalle -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol