JTS 1.14 was released a few days ago. It has split the project into separate artifacts on Maven Central [0] where the old 'jts' artefact is now 'jts-core'.
The upstream SVN repository and its ant build.xml [1] do not build these individual artefacts. That has remained largely unchanged compared to 1.13. In Debian, JTS is required for h2database, elasticsearch & libspatial4j-0.4-java. These are likely to use at least the new jts-core Maven artefact when they update to JTS 1.14, instead of the old jts artefact as they do now. Some mangling in maven.rules should be sufficient to deal with that. The upstream tarball (zip file more specifically), doesn't contain the source code separately any more, that has been moved to source JARs. And the content of these source JARs are different from those available on Maven Central. For the jts Debian package we can switch to the SVN sources with a custom get-orig-source target for the upstream tarball, or we can unpack the source JARs with a custom script in the watch file. The latter will keep packaging close to what we had for JTS 1.13. The former will allow us to build the other artefacts available on Maven Central too (jts-app & jts-example in particular). I'll start by unpacking the source JARs from the zip file for the initial packaging update to 1.14, we can decide to adopt the modular approach like Maven Central when reverse dependencies show a need for this. JTS 1.14 will be uploaded to experimental first, and which the impact on the reverse dependencies can be evaluated. [0] http://central.maven.org/maven2/com/vividsolutions/ [1] http://sourceforge.net/p/jts-topo-suite/code/HEAD/tree/tags/Version_1.14/ Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1