Commit fc7668c0 authored by Bas Couwenberg's avatar Bas Couwenberg

New upstream version 1.15.0+ds

parent a09b6f31

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

\ No newline at end of file
language: java
- oraclejdk8
sudo: false
- $HOME/.m2
install: mvn install -B -V
# Contributing to JTS
The project welcomes contributions. JTS is a mature, widely-used library, so contributions will be reviewed carefully to ensure they do not compromise the quality of the codebase.
To start, it helps to announce what you are working on ahead of time to confirm that it is an acceptable contribution. To do this post to the [JTS Mailing List](
The following sections outline workflows involved with contributions.
## Become a Contributor
In order to have code contributions accepted, the submitter must:
1. Sign the [Eclipse Contributor Agreement]( (ECA) with the Eclipse Foundation. Use the registered email with the Git commits associated to the GitHub pull request.
## Develop a Contribution
Code contributions must include a license header at the top of each file. A sample header for Java files is [here](doc/sample_java_header.txt).
Code contributions should include the following:
* Javadoc on classes and methods
* Unit Tests to demonstrate code correctness and allow this to be maintained going forward. In the case of bug fixes the unit test should demonstrate the bug in the absence of the fix (if any). Unit Tests are usually JUnit classes, or in some cases may be JTS TestRunner test cases
* License information on __all__ provided source files. An example license header can be found [here](doc/sample_java_header.txt).
## Make a Pull Request
The easiest and most visible way to make a contribution is to submit a Pull Request (PR) to the [GitHub repo](
When preparing a PR please do the following:
1. Acknowledge that the code contribution is IP clean by 'signing off' the commits in the pull request with the '-s' option to 'git commit'.
2. Labeling the PR helps to track and prioritize the contribution. Use the following labels:
* The contribution type: enhancement, bug, api
* The module being contributed to: jts-core, jst-io, jts-app, jts-doc, jts-build
3. When a PR is submitted Travis CI will run to check the commiter Eclipse status and the build correctness.
Please check the PR status, and fix any reported problems
If you have questions about this, please ask on the jts-dev list.
# JTS Developing Guide
## Building
The JTS build chain uses Maven. Build commands are executed at the project root directory (this one).
* Build JTS, with tests:
mvn clean install
* Build JTS, no tests:
mvn clean install -DskipTests
* Build `jts-io-ora`:
mvn install -Poracle
* Build `jts-io-sde`:
mvn install -Parcsde
* Build everything:
mvn install -Pall
## Javadoc
* Build Javadoc for core modules
mvn javadoc:aggregate
## Eclipse Configuration
* Generate Eclipse configuration using `mvn eclipse:eclipse`
* Import the generated projects into an Eclipse workspace
### Run Configurations
It is convenient to define the following Run Configurations:
* **JTS TestRunner** - for executing XML tests:
Field | Value
Type | Java Application
Project | `jts-tests`
Main class | `org.locationtech.jtstest.testrunner.JTSTestRunnerCmd`
Program arguments | `-files validate general`
Working directory | `${workspace_loc:jts-tests/src/test/resources/testxml}`
* **JTS TestBuilder** - for viewing and processing geometry with JTS
Field | Value
Type | Java Application
Project | `jts-app`
Main class | `org.locationtech.jtstest.testbuilder.JTSTestBuilder`
Program arguments (optional) | `-geomfunc <classname> ...`
VM args | `-Xmx1000M`
VM args (optional, for Mac) | `-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel`
Working directory | Default
## Testing
JTS aims for 100% code coverage for unit tests.
There are two kinds of unit tests:
### JUnit tests
Used for verifying API code, internal data structures, and ancillary algorithms.
### XML Tests
JTS provides a code-independent, declarative XML-based format for expressing geometric functional tests.
This format has the following advantages:
* allows encoding large geometries
* provides geometric test cases in a reusable way
* easily consumed by external tools such as the JTS TestBuilder or other geometry libraries (e.g. GEOS)
* allows geometric tests to be used with other operation implementations, for testing or comparison purposes
This format should be used for tests which involve large geometries, or which
express fundamental geometric semantics of the JTS library.
# JTS Licensing FAQ
JTS is dual-licensed under:
* the [Eclipse Public License 1.0]( ("EPL")
* the [Eclipse Distribution License 1.0]( (a Revised BSD-style license).
More detail is provided in the [LICENSES]( document.
This FAQ clarifies the implications of the JTS software licensing.
## Terminology
* **Downstream projects** are codebases which link to JTS libraries
* e.g. GeoTools, GeoServer, etc.
* **Derivative projects** are ports of JTS to other languages
* e.g. GEOS, JSTS, etc.
## Licensing Frequently Asked Questions
**A1. What is the difference between EDL and Revised BSD?**
Revised BSD is a license *family* (see [Wikipedia entry](
Revised BSD is also known as "Modified BSD", "BSD 2.0" or "3-clause BSD". It is a less restrictive version of the original BSD license.
EDL is the actual defined license.
It is called that because Eclipse is the distributing organization.
**A2. JTS no longer uses LGPL. What does this mean for downstream projects?**
JTS is now released under a dual license: EDL **or** EPL.
Dual-licensing gives downstream projects their choice of either:
* The **EDL** is a Revised BSD-style license. This license is **more** permissive than the LGPL, allowing a wider variety of uses.
* The **EPL** provides a similar permissiveness to LGPL, with different wording around patents and requires a notice of where source code for JTS is available.
The choice of which license to use is up to you.
**A3. But I thought LGPL and EPL do not mix? How does this affect derivative projects like the LGPL GEOS project?**
An LGPL project (like GEOS or GeoTools) can use JTS as a dependency, under the terms of the EDL license.
The three clauses in the EDL (common to all BSD-style licenses) allow GEOS to
port the JTS work to C and distribute the resulting work under the LGPL.
Although the LGPL license contains additional restrictions
(notably a requirement to share modifications under the same license)
that exceed what is required by the EDL, these do not conflict with the EDL.
For further information about the compatibility of Revised BSD-style licenses
with the GPL see the [FSF License Comments](
**A4. How can an LGPL-licensed project (such as GEOS) contribute code to JTS?**
From the JTS perspective this works in the same way as any other contribution.
The contributor must have an Eclipse *Contributor License Agreement* (CLA) in place.
For details see the [**Contributing Guide**](
Code contributed to JTS **must** be releasable under the EDL & EPL licenses.
Therefore the contributor must have permission from the contributing project (e.g. via OSGeo CLA or similar)
to relicense the work in question.
# JTS Topology Suite Licensing
May 30th, 2017
## Project Licenses
The Eclipse Foundation makes available all content in this project ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of either the [Eclipse Public License 1.0]( ("EPL") or the [Eclipse Distribution License 1.0]( (a BSD Style License). For purposes of the EPL, "Program" will mean the Content.
If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributor's license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at