The Maven Quickstart had one goal - to get you something on screen starting with only the source code.

But there is a lot more you can do with our build environment

Dependency on Geotools 2.4.x There is a dependency from Geoserver 1.6.x on Geotools 2.4.x (trunk) so you will need to Build GeoTools 2.4.x before Geoserver will compile. GeoTools is supposed to deploy every day - but many developers will work on both over the course of a day.

Compiling a Single Module

To build a single module:

1. Change to root of the specific module
2. Execute the maven compile command

[/dev/geoserver/main]% mvn compile

Dependencies When building a module in isolation, you may receive compile errors due to unsatisfied dependencies on other GeoServer modules. In this case try compiling all modules from the root, then compiling again the specific module again in isolation.

Building a Single Module

From the root of the module:

[/dev/geoserver/main]% mvn install

Web Module and "Configurations"

Several configurations for GeoServer are available here:

• http://svn.codehaus.org/geoserver/trunk/configuration
• 6 Configuration Files

1 Command Line System Properties

The configId and configDirectory can be specified on the command line when building the web module:

[/dev/geoserver/web]% mvn install -DconfigDirectory=/home/bob/geoserver/configuration -DconfigId=citewfs

2 Environment Variables

The properties may also be specified as environment variables on your system. See documentation for setting environment variables for your system. Example with a linux bash shell:

[/dev/geoserver/main]% export configDirectory=/home/bob/geoserver/configuration
[/dev/geoserver/main]% export configId=citewfs
[/dev/geoserver/main]% mvn clean install

3 Maven settings.xml

Repeatedly specifying these properties as command line parameters can get tiresome. A good alternative is to place them in your maven settings.xml file, located in <home directory>/.m2/settings.xml:

<settings>
 ...
 <profiles>
    <profile>
    <activation>
       <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
      <configDirectory>/home/bob/geoserver/configuration</configDirectory>
      <configId>citewfs</configId>
    </properties>
    </profile>
  </profiles>
 ...
</settings>

A combination of the above methods will probably be the most useful for you. For instance one could set an environment variable for the configDirectory property since it is not likely to change. Then the configId parameter may be specified on the command line as a system property during the build.

4 Web Module pom.xml

You may also edit the properties directory in the web pom.xml file, in the properties section located near the end of the pom:

...
  <properties>
    <configDirectory>/home/bob/geoserver/configuration</configDirectory>
    <configId>citewfs</configId>
  </properties>
</project>

This method is not recommended as you risk committing information specific to your local environment.

Building a Module Without Running Tests

You should always run the tests, but you may want to occasionally not run them. To do that use the following command:

mvn -Dmaven.test.skip=true install

Jetty Run

To Use Another Port

To start up jetty on another port you can modify add a connectors section to your pom.xml file:

<configuration>
         <contextPath>geoserver</contextPath>
         <connectors>
             <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                 <port>80</port>
                 <maxIdleTime>10000</maxIdleTime>
             </connector>
         </connectors>
     ....

Build-Run Workflow

In general, when you make a code change to a module in your development environment you must:

1. Rebuild the module that was changed
2. Restart Jetty

As an example, if you make a change to the wfs module:

[/dev/geoserver]% cd wfs
[/dev/geoserver/wfs]% mvn install
[/dev/geoserver/wfs]% cd ../web
[/dev/geoserver/web]% mvn jetty:run

Web Module If you are only making a change to the web module you do not need to rebuild so you can skip step 1. Depending on the change you may be able to skip step 2 as well and have the server pick up the change while running. However you might want to restart the server just to ensure the change was picked up properly. As an alternative, if you're using Eclipse you can start Jetty directly from your development environment, for more details refer to the Eclipse quickstart document.

Javadoc generation

From the root of the geoserver source tree:

[/dev/geoserver]% mvn javadoc:javadoc

will generate a complete javadoc or all geoserver modules into {{/dev/geoserver/target/site/apidocs}.

You may also want to generate javadocs with embedded UML class diagrams. These are generated using
UMLGraph, with the following pre-requisites:

• run maven with jdk 1.5 instead of 1.4
• have GraphViz installed on the box, with dot.exe on the path (this happens automatically on Windows if you use the installer, and on Linux if you're using your distribution packages, don't know about the Mac).

Once prerequisites are satisfied, you can generate the docs with UML diagrams embedded running:

[/dev/geoserver]% mvn javadoc:javadoc -Duml

Community Modules

Community modules can be brought into the build via profiles. To build all community modules:

mvn clean install -P community

To build a single community module:

mvn clean install -P geosync

There must be a profile defined for this module.

To include a community module as a dependency in web.xml:

[web]% mvn clean install -P geosync,geosearch,rest

The three above profiles correspond to modules that will be included in the build when specified.