企业官网建设流程全解析

简介：GeoTools 28.2版本依赖包是面向Java平台的开源地理空间库的完整依赖集合，主要为地理数据处理开发者服务，可直接用于解决GIS项目中逐一查找、匹配和引入对应jar包的麻烦，适合需要构建矢量栅格数据读写、坐标转换、空间分析等功能的Maven或普通工程。压缩包共279个文件，其中266个jar为各模块核心依赖，涵盖数据存储、数据渲染、坐标参考系统以及JAI、JTS等第三方库；另有12个html文档页和1个java示例，分别用于查看许可说明与快速上手。资源包大小约95.09MB，目前已有819人浏览学习，下载后可直接按目录核对依赖版本，减少版本冲突风险，省去手工维护依赖的精力。借助这份整理好的依赖集合，开发者可快速搭建GeoTools运行环境，并利用其内置EPSG数据库和OGC标准支持，将重点放到具体业务逻辑上，从而让复杂的空间数据操作变得更可控、更高效。

geotools 28.2 版本 所有jar包 依赖

做Java GIS开发的朋友，十有八九都跟GeoTools打过交道。这玩意功能是真的强，从WMS/WMTS服务对接、Shapefile读写，到坐标系转换、空间拓扑分析，基本上GIS后端该有的能力它都包圆了。但你要说它有什么让人头疼的地方，依赖管理绝对能排前三——jar包又多又碎，版本还动不动就变，啥时候引入的传递依赖缺了、冲突了，排查起来能让人血压升高。

我这篇文章就围绕GeoTools 28.2这个版本，把它的jar包构成、Maven依赖坐标、仓库配置、离线导入这些事彻底聊透。不管你是刚接触GeoTools的新手，还是被依赖问题折磨过的老手，照着这篇文章的思路走一遍，基本能少踩一半的坑。

1. GeoTools 28.2版本的整体认知

1.1 为什么是28.2这个版本

GeoTools的版本号策略比较有规律：大版本28对应的是2023年发布的系列，而28.2是这个系列里的一个维护版本。这个版本属于支持JDK 8+的版本线，打包方式用的还是传统的jar包形式，没有走JPMS模块化那一套，所以对很多还在用Spring Boot 2.x、JDK 8/11的老项目来说，兼容性反而是最舒服的。

我当时给一个数据治理平台做升级，原来用的是22.x，一堆自定义的FeatureType处理逻辑要迁移。查了一圈之后锁定了28.2，理由很实在：它修复了不少关于Shapefile读写和坐标参考系统（CRS）解析的bug，而且社区里相关的资料比较多，出了问题也好搜。选版本这事，真的不是越新越好，关键是稳定性和你项目里其他框架的兼容性。

1.2 28.2的模块化特点

GeoTools和Spring Boot的思路有点像，它不是一个单独的jar，而是一组按功能拆分的模块。比如gt-shapefile管矢量数据读写，gt-geojson管GeoJSON解析，gt-referencing管坐标系，gt-main是核心数据模型，gt-api是接口定义。

这意味着你引入依赖的时候，不需要“把所有jar包都拉下来”，而是按需引入。但问题也出在这——很多初学者不知道某个功能对应哪个模块，干脆全加一遍，然后Maven就给你搞出一堆传递依赖冲突。28.2版本共有上百个模块jar，我需要做的第一件事就是理清楚每个场景到底该引哪些。

2. Maven依赖坐标与仓库配置

2.1 核心BOM依赖

GeoTools官方提供了一个BOM（Bill of Materials）叫geotools-bom，用来统一管理所有模块的版本号。你只要在dependencyManagement里声明一次，后面引入具体模块的时候就不用写版本号了，避免你自己拍脑袋写错版本导致一堆NoSuchMethodError。

<dependencyManagement> <dependencies> <dependency> <groupId>org.geotools</groupId> <artifactId>geotools-bom</artifactId> <version>28.2</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

用BOM的好处除了版本统一，还有个隐藏优势：它把模块之间的内部依赖版本都锁好了，能把很多隐性的版本错配问题扼杀在编译阶段。

2.2 常用模块的Maven坐标

下面是我在实际项目中经常用到的几个坐标组合，可以直接抄。注意gt-geojson这个模块在28.x版本里包名和依赖范围有些调整，如果你从旧版本升上来，最好检查一下相关类的import路径。

<!-- 核心数据模型 --> <dependency> <groupId>org.geotools</groupId> <artifactId>gt-main</artifactId> </dependency> <!-- 数据访问抽象层 --> <dependency> <groupId>org.geotools</groupId> <artifactId>gt-data</artifactId> </dependency> <!-- Shapefile 读写 --> <dependency> <groupId>org.geotools</groupId> <artifactId>gt-shapefile</artifactId> </dependency> <!-- GeoJSON 解析 --> <dependency> <groupId>org.geotools</groupId> <artifactId>gt-geojson</artifactId> </dependency> <!-- 坐标系参考与转换 --> <dependency> <groupId>org.geotools</groupId> <artifactId>gt-referencing</artifactId> </dependency> <!-- EPSG 坐标系库 --> <dependency> <groupId>org.geotools</groupId> <artifactId>gt-epsg-hsql</artifactId> </dependency>

如果你的项目需要用到WMS、WFS这类OGC服务对接，再补一个gt-wms和gt-wfs。需要提醒的是，gt-wms在28.x系列里对应的底层HTTP客户端已经逐步向Java 11的java.net.http靠拢，如果你的运行环境是JDK 8，得留意一下是否能正常工作。

2.3 osgeo仓库的配置

GeoTools的jar包不在Maven中央仓库里，人家在自家的OSGeo仓库发布。所以光加依赖坐标不够，还得在pom.xml的repositories节点里声明仓库地址。

<repositories> <repository> <id>osgeo</id> <name>OSGeo Release Repository</name> <url>https://repo.osgeo.org/repository/release/</url> </repository> </repositories>

这里有个坑：OSGeo仓库还区分release和snapshot两个仓库。如果你不小心把snapshot仓库配到了生产构建里，某些依赖会拉到不稳定的快照版本，构建结果看起来能用，但过几天再构建可能就是另一套代码了。所以生产环境构建、打正式包，尽量只保留release仓库，快照仓库单独留一个profile给开发环境用。

3. 获取全部jar包的实操方法

3.1 用Maven依赖树梳理完整的jar包列表

虽然我前面说按需引入是个好习惯，但现实中总有特殊场景，比如做离线部署、写二次开发SDK、或者把GeoTools打包成胖jar给下游用，这时候就需要把整个依赖链上的所有jar包完整导出来。

第一步是构建出一个“全量”的依赖清单。我通常的做法是维护一个独立工程，把可能用到的模块坐标全部列进去，然后执行Maven的依赖树命令：

mvn dependency:tree -Dverbose -Dincludes=org.geotools

执行完之后，Maven会像一棵树一样展示每个模块下面挂了哪些子依赖。你会发现很多gt-*模块又依赖了jt-*系列的包（比如jt-utils、jt-epsg），这些是GeoTools底层封装的Java Topology Suite相关工具库，缺了它们很多几何运算会直接崩。

3.2 离线导出所有jar包

如果你需要把所有jar包导出到一个目录里，最省事的方法是Maven的dependency:copy-dependencies插件：

mvn dependency:copy-dependencies -DoutputDirectory=./libs

这个命令会把当前工程所有依赖（包括传递依赖）的jar包复制到你指定的目录下。导出的目录结构里就是平铺的jar包文件，没有多余的层级。如果你还想把source包、javadoc包一起拉下来，加上-Dclassifier=sources或者-Dclassifier=javadoc就行。不过实际来看，sources包通常只在调试时用，生产环境没必要占那个空间。

3.3 打包产物里的lib目录结构

如果你做的是传统的war包或者独立应用，想让最终产物自带所有依赖，建议看一下打包后的lib目录是否完整。以Spring Boot项目为例，spring-boot-maven-plugin默认会把所有依赖打进BOOT-INF/lib，但GeoTools里面有个别模块存在SPI的配置文件合并问题，直接打包可能丢服务定义。

稳妥的做法是在pom.xml里要用maven-shade-plugin做一个fat jar，并配置ServicesResourceTransformer，把META-INF/services下的SPI文件合并，否则运行时会报类似“No suitable driver found”或“Factory is null”的错。

4. 核心依赖的底层解析与版本坑

4.1 常见的传递依赖冲突

GeoTools 28.2的核心依赖里有几个高频冲突源，我列一下大家感受会更深：

• org.locationtech.jts:jts-core：这个包是几何算法的基础。很多项目会直接引JTS，如果版本号低于GeoTools要求的版本，运行时会出现TopologyException或者类转换异常。
• org.apache.commons:commons-lang3：GeoTools内部大量用到commons工具包，如果你项目里其他框架引的commons版本特别老，也会冲突。
• com.fasterxml.jackson.core:jackson-databind：处理GeoJSON时必定用到，版本一旦不一致，轻则序列化报错，重则直接抛InvalidDefinitionException。
• org.hsqldb:hsqldb：这个只有在用gt-epsg-hsql的时候才会出现，如果不用它，可以把模块排除掉，减小依赖体积。

4.2 JDK版本与坐标参照库的兼容性

GeoTools 28.2对JDK 8的兼容做得还可以，但有个地方要注意：gt-referencing模块在解析EPSG坐标库的时候会加载一些内置的数据库和属性文件，如果JDK的--add-opens没配好，在高版本JDK（11+）上运行有概率出现模块访问限制报错。

我在本地用JDK 11跑过28.2，当时启动参数里加了这些：

--add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.desktop/java.awt.geom=ALL-UNNAMED

如果你用JDK 8，一般不用管这些。用JDK 17的兄弟就要特别注意，前两个--add-opens大概率得加，否则程序启动时会有IllegalAccessError。

4.3 与Spring Boot的兼容性实操

结合前一节提到的jar包需求，在Spring Boot项目里引入GeoTools 28.2需要额外注意依赖版本控制。我建议直接在pom.xml里用一个profile来管理GeoTools相关依赖，避免影响Spring Boot自己的BOM：

<profiles> <profile> <id>geotools</id> <dependencyManagement> <dependencies> <dependency> <groupId>org.geotools</groupId> <artifactId>geotools-bom</artifactId> <version>28.2</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> </profile> </profiles>

配置好之后，在集成测试里写一个最简单的数据读取验证：

FileDataStore store = FileDataStoreFinder.getDataStore(new File("your.shp")); SimpleFeatureSource featureSource = store.getFeatureSource(); SimpleFeatureCollection features = featureSource.getFeatures(); System.out.println("feature count = " + features.size()); store.dispose();

能正常输出feature数量，说明你的jar包依赖和SPI配置基本是健康的。这一步能验证gt-shapefile、gt-main、gt-data以及JTS相关的jar包都正确加载了。

5. 常见问题与排查技巧实录

5.1 问题速查表

下面这些情况，都是我在实际项目里和社区里高频见到的，归纳成表方便大家对照排查。

5.2 缺少gt-*.jar时的定位思路

如果你报错信息里出现了gt-开头的类名,比如org.geotools.referencing.CRS，但类找不到，定位思路很简单：用类名反查模块。GitHub上搜类名、或者在IDE里按类名检索依赖库，先确认这个类属于哪个模块，再回到pom.xml里补坐标。

我以前最常犯的错是把gt-referencing记成gt-crs，名字完全不一样，怎么可能搜得到。还有gt-epsg-hsql和gt-epsg-wkt的区别：前者用一个内嵌的HSQL数据库存EPSG定义，内存占用更大但查询灵活；后者用WKT格式定义存储，轻量但EPSG覆盖范围少。28.2版本里如果你只做几个常用坐标系的转换，gt-epsg-wkt就够了，能省不少体积。

5.3 私有仓库与离线环境的依赖方案

企业内部开发经常遇到外网受限的情况，Maven依赖拉不下来，或者说OSGeo仓库在公司内网不可达。我的建议是准备一台内部私服（比如Nexus或Artifactory），先从外网机器上把所有GeoTools相关的依赖jar包拉下来，然后批量上传到私服。具体的操作可以通过Nexus的REST API或者Web页面上传，上传完毕后把pom里的仓库地址直接换成私服地址，其他同事构建的时候就能走内网了。

更省事的方法是用mvn dependency:go-offline在能联网的机器上先把本地仓库填充好，然后把整个~/.m2/repository目录打成tar包同步到内网，在离线环境里配置settings.xml里的localRepository指向这些本地文件。我就是这么做的，那些org/geotools、org/locationtech目录下的jar包全在本地仓库里，速度比在线拉取还快。

5.4 排查过程中的独家心得

排查GeoTools依赖问题，我有个个人习惯：先跑一个最小可复现的demo工程，只保留必要模块。如果这样能跑通，再逐步往正式项目里加东西，问题就缩小在某个模块的冲突上。这里有个容易忽略的点，就是gt-geojson模块在28.x里依赖了com.fasterxml.jackson.core的2.13+版本，而你项目里Spring Boot自带的可能是2.11，这时候GeoTools处理中文GeoJSON字段时会出现乱码或者序列化异常，单纯靠排除依赖还不够，得把jackson的整体版本对齐。

另外，排查的时候多利用IDE的Maven面板，IDEA里右键依赖列表就可以看到哪几个jar包存在版本冲突，可以直接跳到pom文件里按冲突位置处理。我见过不少同事把这个功能忽略掉，真的挺可惜的。

6. 进阶思考与额外扩展

实际项目中我还有一个小技巧：在正式发布应用之前，跑一遍mvn dependency:analyze，它能把“声明了但没用到”的依赖和“用到但没声明”的依赖都列出来。GeoTools这种模块较多的库，很容易出现冗余依赖，清理之后部署包能小不少，启动速度也会快一些。

如果后续想把GeoTools 28.2的依赖彻底固化，另一个思路是直接把geotools-bom单独打成一份pom放到私服，然后项目里统一引用私服上的这份BOM。这样一来，多个微服务之间用GeoTools的版本完全一致，升级的时候也只需要改私服里那一份BOM的版本号，不用每个服务都去动pom。

至于GeoTools后面更新的版本，有些模块（比如gt-geojson）还在持续演进，如果你不是非要追新功能，28.2作为一个维护版本其实已经很够用了。等到项目里需要JDK 17+的完整虚拟线程支持、或者想用上更新的OGC API标准时，再考虑升级也不迟。切记升级前对比官方文档里标注的Breaking Changes，把jar包变化和API变化列个清单，按计划替换，大概就是这个项目的依赖管理最稳的路子。

本文还有配套的精品资源，点击获取