On Mar 19, 2010, at 6:36 PM, Jean-Vincent Drean wrote: I've thought about it but it doesn't mean much IMO since: - hibernate.cfg.xml require configuration to work - default values should be in the code and not in the config files since XWiki should work with no xwiki.properties or xwiki.cfg.

Yes, for values that don't have default in the code, I think we should move the in the code. Actually that's: UC5: Make XWiki work without configuration files. Solution for UC5: * Put default values in the code so that XWiki works if there's no xwiki.cfg, xwiki.properties or hibernate.cfg.xml files. We would default to HSQLDB by default.

On Fri, Mar 19, 2010 at 19:03, Vincent Massol <vincent(a)massol.net> wrote: Don't mix platform default and XE default configuration values.

> Solution for UC5: > * Put default values in the code so that XWiki works if there's no xwiki.cfg, xwiki.properties or hibernate.cfg.xml files. We would default to HSQLDB by default. > > WDYT? > > Thanks > -Vincent

On Fri, Mar 19, 2010 at 6:47 PM, Vincent Massol<vincent(a)massol.net> wrote: It'd be perfect but some values aren't in the code, and some shouldn't be imho, the first example I can think of is the list of plugins.

Hi, I'd like to propose a small variation which is to consider WEB-INF/* properties as default values and all the other location are overrides. Thus to summarize: Use Cases: UC1: Easy install: no need to explode the XAR to install XWiki. See also the comment about xwiki on http://java.dzone.com/articles/file-system-storage-and UC2: Easy upgrade: no need to take care about saving the configuration so that it's not overwritten by an upgrade UC3: Should be possible to have multiple installs on the same machine and running at the same time UC4: Should be possible to control the location of the configuration files for our automated functional tests (so that we control the configuration used) UC5: Make XWiki work without configuration files Implementation: 0) Read the default properties from xwiki.cfg and xwiki.properties and the steps below (1) to 4)) will override these default values, so that users only need to define properties they want to override. Note that ideally we would do the same with hibernate.cfg.xml but it's harder to implement since it means merging an XML file. 1) Look for a system property (e.g. xwiki.config.dir) defining a directory location and if defined look for the files in it using File IO (I know it's not JEE kosher but it's acceptable IMO, especially since it won't break and we'll fallback in case of problem). Could be relative or absolute. 2) If not found, look for a JNDI property that gives the location of the config directory 3) If not found, look for config files in [user.home]/.xwiki wdyt?

Thanks -Vincent On Mar 19, 2010, at 6:08 PM, Vincent Massol wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi, I'd like to propose a small variation which is to consider WEB-INF/* properties as default values and all the other location are overrides. Thus to summarize: Use Cases: UC1: Easy install: no need to explode the XAR to install XWiki. See also the comment about xwiki on http://java.dzone.com/articles/file-system-storage-and UC2: Easy upgrade: no need to take care about saving the configuration so that it's not overwritten by an upgrade UC3: Should be possible to have multiple installs on the same machine and running at the same time UC4: Should be possible to control the location of the configuration files for our automated functional tests (so that we control the configuration used) UC5: Make XWiki work without configuration files Implementation: 0) Read the default properties from xwiki.cfg and xwiki.properties and the steps below (1) to 4)) will override these default values, so that users only need to define properties they want to override. Note that ideally we would do the same with hibernate.cfg.xml but it's harder to implement since it means merging an XML file. 1) Look for a system property (e.g. xwiki.config.dir) defining a directory location and if defined look for the files in it using File IO (I know it's not JEE kosher but it's acceptable IMO, especially since it won't break and we'll fallback in case of problem). Could be relative or absolute. 2) If not found, look for a JNDI property that gives the location of the config directory 3) If not found, look for config files in [user.home]/.xwiki

wdyt? Thanks -Vincent On Mar 19, 2010, at 6:08 PM, Vincent Massol wrote: > Hi devs, > > I've been wanting to make it easy to upgrade XWiki from one version to another for some time (I'm not talking about XAR upgrade here, that's the extension manager). I'm talking about XWiki configuration files. > > Here are the use cases I'd like to solve: > > UC1: Easy install: no need to explode the XAR to install XWiki. See also the comment about xwiki on http://java.dzone.com/articles/file-system-storage-and > UC2: Easy upgrade: no need to take care about saving the configuration so that it's not overwritten by an upgrade > UC3: Should be possible to have multiple installs on the same machine and running at the same time > UC4: Should be possible to control the location of the configuration files for our automated functional tests (so that we control the configuration used) > > The configuration files I'm talking about are: > * xwiki.cfg > * hibernate.cfg.xml > * xwiki.properties > > Proposed Solution: > =============== > > 1) Look for a system property (e.g. xwiki.config.dir) defining a directory location and if defined look for the files in it using File IO (I know it's not JEE kosher but it's acceptable IMO). Could be relative or absolute. > 2) If not found, look for a JNDI property that gives the location of the config directory > 3) If not found, look for config files in [user.home]/.xwiki > 4) If not found, emit an error explaining how to configure xwiki > > 1) solves UC3 and UC4 > 2) solves UC3 > 3) solves UC1 and UC2 > > Note > ==== > > I'm not suggesting any backward compatibility here since it's a new way of configuring XWiki. It means upgraders will need to read the release notes/doc to understand how to configure XWiki. > > If really needed, we could devise a backward compat strategy, but I'm not sure we absolutely need that. > > WDYT?