Development¶

Setting Up¶

1. The Maven build system respects the current setting of JAVA_HOME.

   To define JAVA_HOME be sure to point to the root directory of your JDK.

   Windows:

   set JAVA_HOME=c:\Program Files\Temurin\jdk8u322-b06
   

   Linux/OS X:

   export JAVA_HOME=/opt/jdk1.7.0_79
   

2. You can download maven from http://maven.apache.org/download.html, unpack and include the bin directory in your PATH variable.

   Windows:

   set M2_HOME = C:\java\apache-maven-3.8.5
   set PATH=%PATH%;%M2_HOME%\bin;%JAVA_HOME%\bin
   

   Linux:

   export M2_HOME = ~/java/apache-maven-3.8.5
   export PATH=$PATH:$M2_HOME/bin:$JAVA_HOME/bin
   

   For more detail instructions on maven see the download page.

3. Test that Maven is installed correctly:

   mvn -version
   

4. Check that you are using the right version of the javac compiler (as this is determined by PATH, not JAVA_HOME):

   javac -version
   

Setting up Eclipse¶

1. Open as Maven project, choose geowebcache folder (containing root pom.xml).

2. Configure Eclipse for working on GeoWebCache files.

   • Navigate to to Java ‣ Code Style ‣ Formatter.

   • Click on Import, choose geowebcache/tools/formatter.xml

3. There is also a geowebcache/tools/codetemplates.xml to assist with creating new files.

4. To run GeoWebCache use the main menu Run ‣ Debug Configurations and double-click on Java Configurations

   • Set Name: GWC

   • The Project: geowebcache

   • For main class, set Start

   Then press Close, or Debug if you want to try it right away.

Setting up InteliJ¶

1. Open as Maven project, choose geowebcache folder (containing root pom.xml).

2. InteliJ has some succes loading Eclipse geowebcache/tools/codetemplates.xml and geowebcache/tools/formatter.xml.

3. To setup a Run Configuration for GeoWebCache uses:

   • org.geowebcache.jetty.Start class

   • program directory: $MODULE_DIR$

   

Setting up Logging¶

• GeoWebCache uses or bridges a number of logging frameworks, requiring the following configuration:

  • log4j2.xml - log4j configuration

  • logging.properties redirecting java util logging to log4j

• Logging in web application controled by WEB-INF/classes/log4j.xml.

  Used by mvn jetty:run-war

• Logging in test-cases is controlled by src/test/log4j2-test.xml.

  Used by mvn jetty:run

• LoggingContextListener can override based on org.geowebcache.util.logging.policy parameter, see Troubleshooting discussion of logging for details.

• Care is taken to exclude org.springframework:spring-jcl:

  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <exclusions>
      <exclusion>
        <artifactId>spring-jcl</artifactId>
        <groupId>org.springframework</groupId>
      </exclusion>
    </exclusions>
  </dependency>
  

  So that the implementation provided by Log4j is used:

  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-jcl</artifactId>
  </dependency>
  

  For more information see org.apache.commons.logging javadocs (although older manual provides a better explanation on how exclusion works).

Contributing patches¶

The preferred way of providing patches is to create an issue in GitHub, develop the patch, and then make a GitHub Pull Request referencing the ticket. If appropriate please backport fixes to the Stable and Maintenance branches. New features may be backported if they have been on Master for a month without issue and if they are backward compatible for users and down stream developers.

In addition to creating the issue ticket, you are highly encouraged to bring it up on the GeoWebCache Developers mailing list first. Other developers or users may have considered the problem before or have other useful input.

Please include unit tests for any patches that change behaviour: For a bug fix, include tests to confirm the bug is fixed, for a new feature include tests to check that the feature works. Please also include the copyright header for the LGPL 3.0 in any new source files.

Please squash your working commits before creating a pull request. The commits in a pull request should represent clear semantic parts of the patch, not the work history. Added extension point -> New module implementing extension point -> Added documentation for new module is a good break down while Did some work -> Work from tuesday -> Stuff I forgot is not.

Avoid non-semantic whitespace and formatting changes as this makes your intent less clear and makes it harder to understand the change history. If you do clean things up, please do so via a separate commit. In particular, please avoid using automatic code formatters to reformat an entire existing file.

Use javadoc comments to document APIs and additional comments to clarify obtuse code. Do not use comments to identify yourself as that’s what the Git history is for. Do not leave commented out code blocks. Commented out examples in human readable config files however are OK.