This page last changed on May 01, 2007 by cholmes.


Allowing developers to easily change data directory configurations without forcing people to download them.

Proposed By

Andrea Aime
Justin Deoliveira

Proposal Type

Build system change
Subversion repository reorganization

Assigned to release

Targets are both Geoserver 1.6 and 1.5




JIRA task:

Email discussion:

Other wiki discussions:

Voting History

+1 Andrea Aime
+1 [~bowens]
+1 Justin Deoliveira
+1 Jody Garnett
+0 rob
+1 gabriel




Geoserver 1.4.x branch introduced the concept of configuration zip files, each containing a different and pre-configured data directory, some to be used for minimal configuration, other for releasing, other for CITE tests, and so on.

Installing one of these into the web module requires a plugin Justin developed, and setting an environemnt variable. For example:

mvn install -DconfigId=release

in order to install the release configuration, which is to be found in the web module, file.
These zip files were to be stored onto external server, but crept in the version control when 1.5.x was created (the issue is, the server that held the config was only avaiable to TOPP people, but also other developers need to be able and alter the configuration files).

There are various downsides with the current situation:

  • these files are big, thus make checking out geoserver harder (especially from places where internet connection is not fast or stable)
  • changing one of them is a tedious process, you have to unzip it, change, zip again, install it and check everything works fine again

We propose to have configuration kept in version control, in a place where people are not forced to download them, but easy for developers to handle and modify. Also each one will have to be a proper data directory, not a mix with service.xml and catalog.xml to be put in WEB-INF instead. Ideally, they can be used just fine by pointing GEOSERVER_DATA_DIR at them.


First step is to rework the geoserver svn layout so that there is a directory for code, and one for configuration.
The result will look like this:

  • geoserver
    • configuration (or data_dirs)
      • minimal
      • release
      • citewfs
      • citewms
      • citewcs
    • code
      • wms
      • wfs
      • ...

This allows people that do not want to checkout the configurationts to get out just the code, whilst allowing developers to have all that's needed to run cite testing and releasing at their fingertips.

Second step is to modify the maven config plugin to copy the data directory from an arbitrary disk location, with two parameters:

  • the configurationsDir, pointing at the root of all data directory configuration
  • the configId, pointing at the chosen configuration

The configurationsDir should be set by the developer as an environment variable once for all, allowing the mvn install to behave just like now.

In order to make the minimal configuration available to the developer that just checked out the code, we'll use the subversion external definition capabilities to link the minimal configuration directly under the web module. By default, we can have the config plugin look in the web module and the minimal configuration so that a mvn install just installs it.


I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
      + trunk
      + branches
      + tags
      + config
          + release
          + minimal
Posted by jdeolive at Jan 25, 2007 12:41

We need to update 7 Policies and Procedures to reflect this GSIP.

Posted by jive at Jan 30, 2007 14:58
Document generated by Confluence on May 14, 2014 23:00