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

Andrea Aime Brent Owens Justin Deoliveira

Build system change Subversion repository reorganization

Targets are both Geoserver 1.6 and 1.5

Completed

JIRA task:

Email discussion:

Other wiki discussions:

+1 Andrea Aime +1 Brent Owens +1 Justin Deoliveira +1 Jody Garnett +0 rob +1 gabriel

None

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, release.zip 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 GEOSERVERDATADIR 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 ***** 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.

• Andrea Aime
• Brent Owens
• Justin Deoliveira