Skip to content

Development Guide ​

This document provides information for developers who want to build, modify, or contribute to the GeoTools library. It covers the development environment setup, build process, continuous integration workflows, and the release process. For information about GeoTools architecture, see Core Architecture.

Development Environment Setup ​

To work with GeoTools source code, you need to set up a proper development environment.

Prerequisites ​

The following are required for GeoTools development:

  • Java Development Kit (JDK):

    • Required: JDK 11 (GeoTools 21.x and above)
    • Optional: JDK 17 for testing against newer Java versions
  • Apache Maven: Version 3.5 or newer recommended

  • Git: For source code management

  • IDE: Eclipse, IntelliJ IDEA, or other Java IDE (optional but recommended)

Installing Java ​

GeoTools currently requires Java 11 for development. You can use OpenJDK or Oracle JDK distributions.

# Using SDKMAN (recommended)
sdk install java 11.0.20.1-tem

# Using apt-get
sudo apt-get install openjdk-11-jdk

Installing Maven ​

Maven is used as the build system for GeoTools.

# Using SDKMAN
sdk install maven

# Using apt-get
sudo apt-get install maven

Git Configuration ​

Configure Git before working with the GeoTools repository:

git config user.name "Your Name"
git config user.email your.email@example.com
git config --global core.autocrlf input

Building GeoTools ​

Getting the Source Code ​

git clone https://github.com/geotools/geotools.git
cd geotools

Repository Structure ​

SVG
100%

Basic Build ​

To build the entire GeoTools library:

mvn clean install

For a faster build without running tests:

mvn clean install -DskipTests

To build with all optional modules:

mvn clean install -Dall

Parallel Builds ​

Maven 3 supports parallel builds to take advantage of multi-core processors:

mvn clean install -Dall -T 2C

The 2C parameter tells Maven to use 2 threads per CPU core.

Building Individual Modules ​

To build a specific module:

cd modules/library/main
mvn clean install

Common Build Issues ​

Continuous Integration and Testing ​

GeoTools uses GitHub Actions for continuous integration testing. The CI process ensures code changes don't break existing functionality.

CI/CD Workflow ​

SVG
100%

Database Integration Tests ​

Database integration tests verify that GeoTools can connect to various database systems:

  • PostgreSQL/PostGIS (postgis_online.yml)
  • MySQL (mysql_online.yml)
  • Oracle (oracle_online.yml)
  • Microsoft SQL Server (mssql_online.yml)
  • DB2 (db2_online.yml)
  • GeoPackage (geopkg_online.yml)

These tests are performed on pull requests to ensure compatibility.

Running Tests Locally ​

To run the tests for GeoTools:

mvn test

To run a specific test class:

mvn -Dtest=YourTestClass test

For testing against online resources like databases, use the online profile:

mvn test -Ponline

Release Process ​

The GeoTools release process involves several steps to ensure quality and consistency.

Release Workflow ​

SVG
100%

Release Prerequisites ​

The following are necessary to perform a GeoTools release:

  1. Commit access to the GeoTools Git repository
  2. Build access to Jenkins
  3. Edit access to the GeoTools Blog
  4. Administration rights to GeoTools JIRA
  5. Release/file management privileges in SourceForge

Building a Release ​

The release build is performed using the build_release.sh script which:

  1. Checks out the appropriate branch
  2. Updates version numbers in all files
  3. Builds the release artifacts
  4. Creates a tag for the release

Example usage:

./build/release/build_release.sh -b 28.x 28.1 username email@example.com stable

Publishing a Release ​

The publish_release.sh script handles:

  1. Deploying to the Maven repository
  2. Uploading artifacts to SourceForge

Example usage:

./build/release/publish_release.sh 28.1 28.x username email@example.com

Creating and Announcing Release Notes ​

After publishing:

  1. Generate release notes from JIRA
  2. Create a GitHub release with the release notes
  3. Announce on GeoTools Blog
  4. Email the mailing lists:

Contributing to GeoTools ​

Contribution Workflow ​

SVG
100%

Contribution Guidelines ​

When submitting contributions:

  1. Talk First Policy: Discuss your changes on the developer mailing list first
  2. Include Tests: Always include test cases for your changes
  3. Follow Conventions: Adhere to GeoTools coding conventions
  4. Proper Commits: Use proper commit messages referencing JIRA issues
  5. Submit Pull Requests: Submit your changes as GitHub pull requests
  6. Sign CLA: For non-trivial changes, submit a Contribution License Agreement

Pull Request Requirements ​

Pull requests should:

  1. Target the main branch (backports handled later)
  2. Include tests covering the changes
  3. Update documentation if the change is visible to end users
  4. Reference a JIRA issue in the commit message
  5. Present small, focused changes (one objective per commit)

Community Resources ​

Mailing Lists ​

Issue Tracker ​

GeoTools uses JIRA for issue tracking:

Developer Chat ​

Commercial Support ​

Commercial support options are available for users with deadlines or requiring professional assistance:

Build Server ​

The GeoTools codebase is monitored by a build server that schedules a compile after each commit:

This Development Guide provides an overview of the key tools and processes for working with the GeoTools codebase. By following these guidelines, you'll be able to effectively build, test, and contribute to the GeoTools project.