29 Jul
2013
29 Jul
'13
6:06 p.m.
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having
XWiki version written as comment in the top of xwiki.cfg (no need for
particular location though).
When an upgrade is performed, it would permit to know if this configuration
file has been merged (new xwiki version) or directly moved (first/previous
xwiki version) from the old webapp.
Do you think it would be feasible?
Thank you in advance.
Guillaume
29 Jul
29 Jul
6:15 p.m.
On 07/29/2013 12:06 PM, Guillaume Fenollar wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having
XWiki version written as comment in the top of xwiki.cfg (no need for
particular location though).
When an upgrade is performed, it would permit to know if this configuration
file has been merged (new xwiki version) or directly moved (first/previous
xwiki version) from the old webapp.
Do you think it would be feasible?
Thank you in advance.
Guillaume
Yes, it's quite easy to do. This file is already being generated by
Maven during the build.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
6:42 p.m.
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <guillaume.fenollar(a)xwiki.com>
wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having
XWiki version written as comment in the top of xwiki.cfg (no need for
particular location though).
When an upgrade is performed, it would permit to know if this configuration
file has been merged (new xwiki version) or directly moved (first/previous
xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed.
* Now you've upgraded your WAR to version N+1
* You merge the xwiki configuration files
. If you don't edit their versions you still have version N mentioned and it's
even worse than before because the next person that comes will see and *trust* that
you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I fear it might
do the opposite...
Actually the config file is supposed to stay stable as you're supposed to use the same
config version across xwiki versions. In the future it'll need to be in the data dir
(except for the location of the data dir which should be something defined in the startup
script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for
example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff
xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml
sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff
xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o
xwiki.new/WEB-INF/xwiki.cfg
sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo
sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o
xwiki.new/WEB-INF/xwiki.properties
sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo
sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o
xwiki.new/WEB-INF/struts-config.xml
sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff
xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o
xwiki.new/templates/admin.vm
sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori;
sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B
-W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard (just before the
distribution wizard runs) to let the user discover new configuration options, deprecated
ones and removed ones. We would just need to add some metadata somewhere in XWiki to
indicate that.
Thanks
-Vincent
Thank you in advance.
Guillaume
7:37 p.m.
The first idea was to merge old configuration lines to the new xwiki.cfg,
which means the version is correct when files are correctly merged. The
issue is also that some lines need to be remove from xwiki.cfg (like
workdir, which is useless in 5.x for example).
Being able to follow the version number could be useful in this case.
Upgrade wizard sounds nice BTW :)
2013/7/29 Vincent Massol <vincent(a)massol.net>
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <
guillaume.fenollar(a)xwiki.com> wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having
XWiki version written as comment in the top of xwiki.cfg (no need for
particular location though).
When an upgrade is performed, it would permit to know if this
configuration
file has been merged (new xwiki version) or
directly moved
(first/previous
xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed.
* Now you've upgraded your WAR to version N+1
* You merge the xwiki configuration files
. If you don't edit their versions you still have version N mentioned and
it's even worse than before because the next person that comes will see and
*trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I
fear it might do the opposite...
Actually the config file is supposed to stay stable as you're supposed to
use the same config version across xwiki versions. In the future it'll need
to be in the data dir (except for the location of the data dir which should
be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files.
We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo
sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o
xwiki.new/WEB-INF/web.xml
sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo
sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o
xwiki.new/WEB-INF/xwiki.cfg
sudo mv xwiki.new/WEB-INF/xwiki.properties
xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff
xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W
-E -o xwiki.new/WEB-INF/xwiki.properties
sudo mv xwiki.new/WEB-INF/struts-config.xml
xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff
xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B
-W -E -o xwiki.new/WEB-INF/struts-config.xml
sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori;
sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W
-E -o xwiki.new/templates/admin.vm
sudo mv xwiki.new/WEB-INF/classes/logback.xml
xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff
xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori
-B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard
(just before the distribution wizard runs) to let the user discover new
configuration options, deprecated ones and removed ones. We would just need
to add some metadata somewhere in XWiki to indicate that.
Thanks
-Vincent
Thank you in advance.
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
30 Jul
30 Jul
11:48 a.m.
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <
guillaume.fenollar(a)xwiki.com> wrote:
I do not understand what you fear, a comment saying "Configuration file
distributed with XWiki version x.y.z" could not really cause an issue to
the merge process, and could help the way Guillaume said without causing
any misinformation from our side anyway.
Administrators could do tons of stupid things while merging, it does not
matter.
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having
XWiki version written as comment in the top of xwiki.cfg (no need for
particular location though).
When an upgrade is performed, it would permit to know if this
configuration
file has been merged (new xwiki version) or
directly moved
(first/previous
xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed.
* Now you've upgraded your WAR to version N+1
* You merge the xwiki configuration files
. If you don't edit their versions you still have version N mentioned and
it's even worse than before because the next person that comes will see and
*trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I
fear it might do the opposite...
Actually the config file is supposed to stay stable as you're supposed to
use the same config version across xwiki versions. In the future it'll need
to be in the data dir (except for the location of the data dir which should
be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files.
We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo
sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o
xwiki.new/WEB-INF/web.xml
sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo
sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o
xwiki.new/WEB-INF/xwiki.cfg
sudo mv xwiki.new/WEB-INF/xwiki.properties
xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff
xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W
-E -o xwiki.new/WEB-INF/xwiki.properties
sudo mv xwiki.new/WEB-INF/struts-config.xml
xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff
xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B
-W -E -o xwiki.new/WEB-INF/struts-config.xml
sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori;
sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W
-E -o xwiki.new/templates/admin.vm
sudo mv xwiki.new/WEB-INF/classes/logback.xml
xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff
xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori
-B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard
(just before the distribution wizard runs) to let the user discover new
configuration options, deprecated ones and removed ones. We would just need
to add some metadata somewhere in XWiki to indicate that.
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Thank you in advance.
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:57 a.m.
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I explained the risk in my mail but I was probably not clear.
Summary:
Having wrong doc is worse than having no doc.
Details:
Having a "Configuration file distributed with XWiki version x.y.z" information
is pretty much useless since this file is **mean*t* to be modified so the information is
only valid if you **don't** modify the file. As soon as you make one modification
it's no longer valid and wrong/misleading for anyone who comes after and read it.
Thanks
-Vincent
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <
guillaume.fenollar(a)xwiki.com> wrote:
I do not understand what you fear, a comment saying "Configuration file
distributed with XWiki version x.y.z" could not really cause an issue to
the merge process, and could help the way Guillaume said without causing
any misinformation from our side anyway.
Administrators could do tons of stupid things while merging, it does not
matter. Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having
XWiki version written as comment in the top of xwiki.cfg (no need for
particular location though).
When an upgrade is performed, it would permit to know if this
configuration
file has been merged (new xwiki version) or
directly moved
(first/previous
xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed.
* Now you've upgraded your WAR to version N+1
* You merge the xwiki configuration files
. If you don't edit their versions you still have version N mentioned and
it's even worse than before because the next person that comes will see and
*trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I
fear it might do the opposite...
Actually the
config file is supposed to stay stable as you're supposed to
use the same config version across xwiki versions. In the future it'll need
to be in the data dir (except for the location of the data dir which should
be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files.
We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo
sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o
xwiki.new/WEB-INF/web.xml
sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo
sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o
xwiki.new/WEB-INF/xwiki.cfg
sudo mv xwiki.new/WEB-INF/xwiki.properties
xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff
xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W
-E -o xwiki.new/WEB-INF/xwiki.properties
sudo mv xwiki.new/WEB-INF/struts-config.xml
xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff
xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B
-W -E -o xwiki.new/WEB-INF/struts-config.xml
sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori;
sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W
-E -o xwiki.new/templates/admin.vm
sudo mv xwiki.new/WEB-INF/classes/logback.xml
xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff
xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori
-B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard
(just before the distribution wizard runs) to let the user discover new
configuration options, deprecated ones and removed ones. We would just need
to add some metadata somewhere in XWiki to indicate that.
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Thank you in advance.
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:01 p.m.
On Jul 30, 2013, at 11:57 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
And to reiterate on what I mentioned in my first reply, a much better solution IMO is:
* Look for xwiki configuration files first in the permanent dir
* If not found there, use the default config files provided with the WAR
If we do this then:
1/ The user has its own config files in data/
2/ The user can clearly see the config files related to the WAR version they got since
they are distributed together
Thanks
-Vincent
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I explained the risk in my mail but I was probably not clear.
Summary:
Having wrong doc is worse than having no doc.
Details:
Having a "Configuration file distributed with XWiki version x.y.z" information
is pretty much useless since this file is **mean*t* to be modified so the information is
only valid if you **don't** modify the file. As soon as you make one modification
it's no longer valid and wrong/misleading for anyone who comes after and read it.
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <
guillaume.fenollar(a)xwiki.com> wrote:
I do not understand what you fear, a comment saying "Configuration file
distributed with XWiki version x.y.z" could not really cause an issue to
the merge process, and could help the way Guillaume said without causing
any misinformation from our side anyway.
Administrators could do tons of stupid things while merging, it does not
matter. Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having
XWiki version written as comment in the top of xwiki.cfg (no need for
particular location though).
When an upgrade is performed, it would permit to know if this
configuration
file has been merged (new xwiki version) or
directly moved
(first/previous
xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed.
* Now you've upgraded your WAR to version N+1
* You merge the xwiki configuration files
. If you don't edit their versions you still have version N mentioned and
it's even worse than before because the next person that comes will see and
*trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I
fear it might do the opposite...
Thanks
-Vincent
>> Actually the config file is supposed to stay stable as you're supposed to
>> use the same config version across xwiki versions. In the future it'll need
>> to be in the data dir (except for the location of the data dir which should
>> be something defined in the startup script as it is now btw ;)).
>>
>> OTOH we could offer first some tools to upgrade the configuration files.
>> We use sdiff for example to upgrade myxwiki.org:
>>
>> sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo
>> sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o
>> xwiki.new/WEB-INF/web.xml
>> sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo
>> sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o
>> xwiki.new/WEB-INF/xwiki.cfg
>> sudo mv xwiki.new/WEB-INF/xwiki.properties
>> xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff
>> xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W
>> -E -o xwiki.new/WEB-INF/xwiki.properties
>> sudo mv xwiki.new/WEB-INF/struts-config.xml
>> xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff
>> xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B
>> -W -E -o xwiki.new/WEB-INF/struts-config.xml
>> sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori;
>> sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W
>> -E -o xwiki.new/templates/admin.vm
>> sudo mv xwiki.new/WEB-INF/classes/logback.xml
>> xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff
>> xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori
>> -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
>>
>> That makes it quite easy to upgrade.
>>
>> For a further future, we could imagine offering a UI in an upgrade wizard
>> (just before the distribution wizard runs) to let the user discover new
>> configuration options, deprecated ones and removed ones. We would just need
>> to add some metadata somewhere in XWiki to indicate that.
>>
>> Thanks
>> -Vincent
>>
>>> Thank you in advance.
>>>
>>> Guillaume
12:08 p.m.
On Tue, Jul 30, 2013 at 12:01 PM, Vincent Massol <vincent(a)massol.net> wrote:
For sure, this is what we want. And the default file could keep a comment
like the one I suggested, this is just the next step.
On Jul 30, 2013, at 11:57 AM, Vincent Massol <vincent(a)massol.net> wrote:
I explained the risk in my mail but I was probably not clear.
Summary:
Having wrong doc is worse than having no doc.
It is not wrong doc for our distributed configuration files. So nothing to
fear, this why I do not understand why you seems to be against that
comment. What will be done with it later is up to the user, and you cannot
prevent him to do stupid things.
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
> On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>> Hi Guillaume,
>>
>> On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <
>> guillaume.fenollar(a)xwiki.com> wrote:
>>
>>> Hello all,
>>>
>>> Platform and Client team of XWiki SAS find interesting the idea of
having
>>> XWiki version written as comment in
the top of xwiki.cfg (no need for
>>> particular location though).
>>> When an upgrade is performed, it would permit to know if this
>> configuration
>>> file has been merged (new xwiki version) or directly moved
>> (first/previous
>>> xwiki version) from the old webapp.
>>>
>>> Do you think it would be feasible?
>>
>> How do you think it would work?
>>
>> * Imagine you have version N installed.
>> * Now you've upgraded your WAR to version N+1
>> * You merge the xwiki configuration files
>> . If you don't edit their versions you still have version N mentioned
and
>> it's even worse than before because
the next person that comes will
see and
*trust* that you're at version N when you're
actually at version N+1.
I don't see how having a comment with the current version will help… I
fear it might do the opposite...
I do not understand what you fear, a comment saying "Configuration file
distributed with XWiki version x.y.z" could not really cause an issue to
the merge process, and could help the way Guillaume said without causing
any misinformation from our side anyway.
Administrators could do tons of stupid things while merging, it does not
matter.
Details:
Having a "Configuration file distributed with XWiki version x.y.z"
information is pretty much useless since this file is **mean*t* to be
modified so the information is only valid if you **don't** modify the file.
As soon as you make one modification it's no longer valid and
wrong/misleading for anyone who comes after and read it.
And to reiterate on what I mentioned in my first reply, a much better
solution IMO is:
* Look for xwiki configuration files first in the permanent dir
* If not found there, use the default config files provided with the WAR
If we do this then:
1/ The user has its own config files in data/
2/ The user can clearly see the config files related to the WAR version
they got since they are distributed together
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Thanks
-Vincent
>> Actually the config file is supposed to stay stable as you're supposed
to
>> use the same config version across xwiki
versions. In the future it'll
need
>> to be in the data dir (except for the
location of the data dir which
should
>> be something defined in the startup
script as it is now btw ;)).
>>
>> OTOH we could offer first some tools to upgrade the configuration
files.
>> We use sdiff for example to upgrade
myxwiki.org:
>>
>> sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo
>> sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o
>> xwiki.new/WEB-INF/web.xml
>> sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori;
sudo
>> sdiff xwiki/WEB-INF/xwiki.cfg
xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E
-o
>> xwiki.new/WEB-INF/xwiki.cfg
>> sudo mv xwiki.new/WEB-INF/xwiki.properties
>> xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff
>> xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori
-B
-W
>> -E -o xwiki.new/WEB-INF/xwiki.properties
>> sudo mv xwiki.new/WEB-INF/struts-config.xml
>> xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff
>> xwiki/WEB-INF/struts-config.xml
xwiki.new/WEB-INF/struts-config.xml.ori
-B
>> -W -E -o
xwiki.new/WEB-INF/struts-config.xml
>> sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori;
>> sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori
-B
-W
>> -E -o xwiki.new/templates/admin.vm
>> sudo mv xwiki.new/WEB-INF/classes/logback.xml
>> xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff
>> xwiki/WEB-INF/classes/logback.xml
xwiki.new/WEB-INF/classes/logback.xml.ori
>> -B -W -E -o
xwiki.new/WEB-INF/classes/logback.xml
>>
>> That makes it quite easy to upgrade.
>>
>> For a further future, we could imagine offering a UI in an upgrade
wizard
>> (just before the distribution wizard
runs) to let the user discover new
>> configuration options, deprecated ones and removed ones. We would just
need
>> to add some metadata somewhere in XWiki
to indicate that.
>>
>> Thanks
>> -Vincent
>>
>>> Thank you in advance.
>>>
>>> Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:30 p.m.
On Jul 30, 2013, at 12:08 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
For sure, this is what we want. And the default file could keep a comment
like the one I suggested, this is just the next step.
> If we do this then:
> 1/ The user has its own config files in data/
> 2/ The user can clearly see the config files related to the WAR version
> they got since they are distributed together
>
> Thanks
> -Vincent
>
>> Thanks
>> -Vincent
>>
>>>> Actually the config file is supposed to stay stable as you're
supposed
> to
>>>> use the same config version across xwiki versions. In the future
it'll
> need
>>>> to be in the data dir (except for the location of the data dir which
> should
>>>> be something defined in the startup script as it is now btw ;)).
>>>>
>>>> OTOH we could offer first some tools to upgrade the configuration
> files.
>>>> We use sdiff for example to upgrade myxwiki.org:
>>>>
>>>> sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo
>>>> sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o
>>>> xwiki.new/WEB-INF/web.xml
>>>> sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori;
> sudo
>>>> sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E
> -o
>>>> xwiki.new/WEB-INF/xwiki.cfg
>>>> sudo mv xwiki.new/WEB-INF/xwiki.properties
>>>> xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff
>>>> xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori
> -B -W
>>>> -E -o xwiki.new/WEB-INF/xwiki.properties
>>>> sudo mv xwiki.new/WEB-INF/struts-config.xml
>>>> xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff
>>>> xwiki/WEB-INF/struts-config.xml
> xwiki.new/WEB-INF/struts-config.xml.ori -B
>>>> -W -E -o xwiki.new/WEB-INF/struts-config.xml
>>>> sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori;
>>>> sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori
> -B -W
>>>> -E -o xwiki.new/templates/admin.vm
>>>> sudo mv xwiki.new/WEB-INF/classes/logback.xml
>>>> xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff
>>>> xwiki/WEB-INF/classes/logback.xml
> xwiki.new/WEB-INF/classes/logback.xml.ori
>>>> -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
>>>>
>>>> That makes it quite easy to upgrade.
>>>>
>>>> For a further future, we could imagine offering a UI in an upgrade
> wizard
>>>> (just before the distribution wizard runs) to let the user discover new
>>>> configuration options, deprecated ones and removed ones. We would just
> need
>>>> to add some metadata somewhere in XWiki to indicate that.
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Guillaume
On Tue, Jul 30, 2013 at 12:01 PM, Vincent Massol
<vincent(a)massol.net> wrote:
This file is not distributed separately. We always distribute it with our WAR and thus it
already has a version: the one of the WAR. I don't see what would be provided more by
adding a version info in it. However I can easily see what can go wrong by doing that.
Guillaume said:
"When an upgrade is performed, it would permit to know if this configuration
file has been merged (new xwiki version) or directly moved (first/previous
xwiki version) from the old webapp."
But I fail to see how adding the version would help for this, except if the user updates
the version comment himself after he merges with the new version. But he can do already by
adding a comment…
Thanks
-Vincent
On Jul 30, 2013, at 11:57 AM, Vincent Massol <vincent(a)massol.net> wrote:
It is not wrong doc for our distributed configuration files. So nothing to
fear, this why I do not understand why you seems to be against that
comment. What will be done with it later is up to the user, and you cannot
prevent him to do stupid things.
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
> On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>> Hi Guillaume,
>>
>> On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <
>> guillaume.fenollar(a)xwiki.com> wrote:
>>
>>> Hello all,
>>>
>>> Platform and Client team of XWiki SAS find interesting the idea of
having
>>> XWiki version written as comment in
the top of xwiki.cfg (no need for
>>> particular location though).
>>> When an upgrade is performed, it would permit to know if this
>> configuration
>>> file has been merged (new xwiki version) or directly moved
>> (first/previous
>>> xwiki version) from the old webapp.
>>>
>>> Do you think it would be feasible?
>>
>> How do you think it would work?
>>
>> * Imagine you have version N installed.
>> * Now you've upgraded your WAR to version N+1
>> * You merge the xwiki configuration files
>> . If you don't edit their versions you still have version N mentioned
and
>> it's even worse than before because
the next person that comes will
see and
>
*trust* that you're at version N when you're actually at version N+1.
>
> I don't see how having a comment with the current version will help… I
> fear it might do the opposite...
>
I do not understand what you fear, a comment saying "Configuration file
distributed with XWiki version x.y.z" could not really cause an issue to
the merge process, and could help the way Guillaume said without causing
any misinformation from our side anyway.
Administrators could do tons of stupid things while merging, it does not
matter.
I explained the risk in my mail but I was probably not clear.
Summary:
Having wrong doc is worse than having no doc. Details:
Having a "Configuration file distributed with XWiki version x.y.z"
information is pretty much useless since this file is **mean*t* to be
modified so the information is only valid if you **don't** modify the file.
As soon as you make one modification it's no longer valid and
wrong/misleading for anyone who comes after and read it.
And to reiterate on what I mentioned in my first reply, a much better
solution IMO is:
* Look for xwiki configuration files first in the permanent dir
* If not found there, use the default config files provided with the WAR
10:41 p.m.
On Tue, Jul 30, 2013 at 12:30 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Jul 30, 2013, at 12:08 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
It is not wrong doc for our distributed configuration files. So nothing to
In production, since currently configuration files are in the war and
should be customized, we need to unzip the war, and therefore the
configuration file does not have anymore a version the way you seems to
expect.
I still do not understand why you fear that much to state in a file what is
it really.
On Tue, Jul 30, 2013 at 12:01 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Jul 30, 2013, at 11:57 AM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>>
>> On Jul 30, 2013, at 11:48 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
>>
>>> On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>>>
>>>> Hi Guillaume,
>>>>
>>>> On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <
>>>> guillaume.fenollar(a)xwiki.com> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> Platform and Client team of XWiki SAS find interesting the idea of
> having
>>>>> XWiki version written as comment in the top of xwiki.cfg (no need
for
>>>>> particular location though).
>>>>> When an upgrade is performed, it would permit to know if this
>>>> configuration
>>>>> file has been merged (new xwiki version) or directly moved
>>>> (first/previous
>>>>> xwiki version) from the old webapp.
>>>>>
>>>>> Do you think it would be feasible?
>>>>
>>>> How do you think it would work?
>>>>
>>>> * Imagine you have version N installed.
>>>> * Now you've upgraded your WAR to version N+1
>>>> * You merge the xwiki configuration files
>>>> . If you don't edit their versions you still have version N
mentioned
> and
>>>> it's even worse than before because the next person that comes will
> see and
>>>> *trust* that you're at version N when you're actually at version
N+1.
>>>>
>>>> I don't see how having a comment with the current version will help…
I
>>>> fear it might do the opposite...
>>>>
>>>
>>> I do not understand what you fear, a comment saying "Configuration
file
>>> distributed with XWiki version
x.y.z" could not really cause an issue
to
>>> the merge process, and could help the
way Guillaume said without
causing
>>> any misinformation from our side
anyway.
>>> Administrators could do tons of stupid things while merging, it does
not
> matter.
I explained the risk in my mail but I was probably not clear.
Summary:
Having wrong doc is worse than having no doc.
fear, this why I do not understand why you seems
to be against that
comment. What will be done with it later is up to the user, and you
cannot
prevent him to do stupid things.
This file is not distributed separately. We always distribute it with our
WAR and thus it already has a version: the one of the WAR. I don't see what
would be provided more by adding a version info in it. However I can easily
see what can go wrong by doing that.
Guillaume said:
"When an upgrade is performed, it would permit to know if this
configuration
file has been merged (new xwiki version) or directly moved (first/previous
xwiki version) from the old webapp."
But I fail to see how adding the version would help for this, except if
the user updates the version comment himself after he merges with the new
version. But he can do already by adding a comment…
If you proceed to an automated tree-way merge, based on, let say:
"Configuration file distributed with XWiki version a.b.c" in the original
war for version n-1
"Customized configuration file for XWiki version a.b.c" in your old webapp
"Configuration file distributed with XWiki version x.y.z" in the new war
for version n
You will surely god what Guillaume expects, which would be "Customized
configuration file for XWiki version x.y.z", and will allow
to differentiate this file from the simple copy of the file from the old
webapp. So, the point of Guillaume is not that bad when used properly.
Thanks
-Vincent
supposed
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
>> Details:
>> Having a "Configuration file distributed with XWiki version x.y.z"
> information is pretty much useless since this file is **mean*t* to be
> modified so the information is only valid if you **don't** modify the
file.
As soon
as you make one modification it's no longer valid and
wrong/misleading for anyone who comes after and read it.
And to reiterate on what I mentioned in my first reply, a much better
solution IMO is:
* Look for xwiki configuration files first in the permanent dir
* If not found there, use the default config files provided with the WAR
For sure, this is what we want. And the default file could keep a comment
like the one I suggested, this is just the next step.
> If we do this then:
> 1/ The user has its own config files in data/
> 2/ The user can clearly see the config files related to the WAR version
> they got since they are distributed together
>
> Thanks
> -Vincent
>
>> Thanks
>> -Vincent
>>
>>>> Actually the config file is supposed to stay stable as you're > to
>>>> use the same config version across xwiki versions. In the future
it'll
> need
>>>> to be in the data dir (except for the location of the data dir which
> should
>>>> be something defined in the startup script as it is now btw ;)).
>>>>
>>>> OTOH we could offer first some tools to upgrade the configuration
> files.
>>>> We use sdiff for example to upgrade myxwiki.org:
>>>>
>>>> sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo
>>>> sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o
>>>> xwiki.new/WEB-INF/web.xml
>>>> sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori;
> sudo
>>>> sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W
-E
> -o
>>>> xwiki.new/WEB-INF/xwiki.cfg
>>>> sudo mv xwiki.new/WEB-INF/xwiki.properties
>>>> xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff
>>>> xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori
> -B -W
>>>> -E -o xwiki.new/WEB-INF/xwiki.properties
>>>> sudo mv xwiki.new/WEB-INF/struts-config.xml
>>>> xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff
>>>> xwiki/WEB-INF/struts-config.xml
> xwiki.new/WEB-INF/struts-config.xml.ori -B
>>>> -W -E -o xwiki.new/WEB-INF/struts-config.xml
>>>> sudo mv xwiki.new/templates/admin.vm
xwiki.new/templates/admin.vm.ori;
>>>> sudo sdiff
xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori
> -B -W
>>>> -E -o xwiki.new/templates/admin.vm
>>>> sudo mv xwiki.new/WEB-INF/classes/logback.xml
>>>> xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff
>>>> xwiki/WEB-INF/classes/logback.xml
> xwiki.new/WEB-INF/classes/logback.xml.ori
>>>> -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
>>>>
>>>> That makes it quite easy to upgrade.
>>>>
>>>> For a further future, we could imagine offering a UI in an upgrade
> wizard
>>>> (just before the distribution wizard runs) to let the user discover
new
>>>> configuration options, deprecated
ones and removed ones. We would
just
> need
>>>> to add some metadata somewhere in XWiki to indicate that.
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4119
days inactive
4120
days old
9 comments
4 participants
participants (4)
-
Denis Gervalle -
Guillaume Fenollar -
Sergiu Dumitriu -
Vincent Massol