企业官网建设流程全解析

简介：一套GeoTools 28.2版本的完整依赖jar包集合，面向需要在Java项目中实现地理数据读写与GIS功能开发的工程师。资源包含该版本核心及周边模块的所有必需依赖，覆盖矢量数据（Shapefile、GeoJSON、KML等）、栅格数据（GeoTIFF等）处理、坐标参考系统转换、空间过滤与渲染，以及对OGC标准（WMS、WFS等）的支持，可帮助快速搭建GeoTools开发环境，免去逐一下载依赖并匹配版本的繁琐过程。压缩包共279个文件，其中266个jar包构成完整的运行与构建依赖，另有12个html文档和1个java示例文件，便于查看许可说明、API文档或进行基础验证。整体大小约95MB，适合已具备Java基础、希望直接引入GeoTools 28.2构建地理空间应用的中高级开发者，也适合在使用Maven或手动配置构建路径时作为依赖缺失时的补充参考。目前已有819人学习下载，能有效节省依赖搜集时间并降低版本冲突风险。 搞GIS的Java后端，项目里第一次引入geotools 28.2的时候，十有八九会在依赖这关卡一下。明明只是想在代码里读写一个Shapefile，pom.xml里加了geotools的jar包坐标，结果mvn compile一跑，直接拉出几十个依赖，时不时还报个“找不到类”“版本冲突”之类的错误，甚至仓库直接404。这篇文章我把geotools 28.2所有jar包的获取方式、核心依赖坐标、传递依赖关系、离线环境怎么收集依赖，以及打包集成时那些坑一次性讲清楚。内容适合两类人：一类是刚接触geotools，想在Spring Boot项目里用JTS几何运算、Shapefile读写这些能力的新手；另一类是已经跑通基础流程，但卡在私服部署、依赖冲突、打包失败这些环节，需要排查思路的老手。

1. geotools 28.2的定位与依赖管理难点

1.1 一套jar包撑起来的GIS工具集

geotools在Java GIS圈子里几乎是绕不开的选择。28.2是28.x系列里的一个稳定小版本，它把空间几何模型（JTS那套）、坐标参考系、栅格与矢量数据读写、空间关系运算这些能力全部拆成了独立模块，每个模块对应一个gt-开头的jar包。严格来说，“geotools 28.2所有jar包”这个说法不太严谨——官方没有提供一个所谓的全家桶jar，而是一堆按功能划分的模块。你也不应该把几十个gt-*.jar全部塞进项目里，正确做法是按需引入。

这个版本线跑在Java 11及以上环境，内部大量使用流式API和Optional，老项目如果还停留在Java 8，建议先评估升级成本。另外，geotools的模块命名比较规律，核心模块是gt-main和gt-metadata，几乎所有功能模块都会间接依赖这两个；读写矢量数据的模块是gt-shapefile、gt-geojson、gt-dxf；处理坐标系的模块是gt-referencing和gt-epsg-hsql；空间数据库扩展是gt-jdbc及其下面的gt-postgis、gt-mysql等。

1.2 为什么geotools依赖这么难管理

抛开代码本身不谈，这个库的依赖管理确实有几个让无数人头疼的根因。

第一，发布仓库不在Maven中央仓库的主路径上。geotools长期通过OSGeo的仓库发布构件，28.2虽然已有部分构件同步到中央仓库，但很多子模块、POM文件和父级依赖依然只在OSGeo仓库里。如果你没有在pom.xml里额外配置OSGeo仓库地址，maven解析依赖时大概率会报“找不到org.geotools:gt-shapefile:jar:28.2”。

第二，传递依赖树非常深。你只引入一个gt-shapefile，它内部会依赖gt-main、gt-metadata、gt-referencing、gt-render等多个模块，而这些模块又分别依赖JTS、CommonMath、Xerces、Jackson等第三方库。实测下来，一个最小可用的geotools项目，最终会拉进来几十个jar包，项目里但凡有其他重量级框架（比如Spring Boot本身），就很容易撞版本。

第三，迭代速度快、API变动频繁。网上很多教程是20.x甚至18.x时代的写法，依赖坐标、类名、方法签名都对不上，照抄过来第一步就可能编译失败。这也是我推荐锁定固定版本、统一由依赖BOM管理的原因。

2. 核心jar包坐标与依赖全景图

2.1 常用模块坐标清单

geotools 28.2的groupId统一是org.geotools，artifactId按功能划分。下面是我在实际项目里用得最多的一组坐标，直接整理成表，方便复制。

以读写Shapefile为例，标准做法是引入gt-shapefile和gt-epsg-hsql两个artifact。注意，不是引入gt-shapefile就完事了，读写带坐标系信息的Shapefile时，如果没有EPSG数据源，到运行时解析坐标系会报错。

2.2 外部强依赖与版本约束

geotools虽然内部模块众多，但它并不会把第三方依赖全部打成fat jar，而是正常声明传递依赖。也就是说，你引入gt-main之后，maven会自动带上JTS、CommonMath、Xerces、json、sqlite-jdbc等第三方库。问题是，这些库的版本和Spring Boot等框架自带的版本经常不一致。

这里我单独说几个容易踩的版本点：

• JTS：geotools 28.2内部使用1.19.0版本的JTS（locationtech.jts），项目里如果还手动引用了旧版jts-core，就会同时存在两套几何类，报java.lang.NoSuchMethodError的概率非常高。
• PostGIS驱动：gt-postgis本身不包含数据库驱动，需要单独引入org.postgresql:postgresql，建议用项目统一版本，避免和Spring Boot数据源冲突。
• Jackson：gt-geojson依赖Jackson 2.x，如果项目里已有其他Jackson版本，要看下是否兼容，冲突通常表现为序列化时方法找不到。
• 日志框架：geotools部分模块用java.util.logging，和Spring Boot的Logback不在一个体系，虽然不会编译报错，但日志输出风格不统一，排查问题时会有点别扭。

2.3 用一条命令看清完整依赖树

与其在网上搜“geotools 28.2所有jar包依赖”的现成清单，不如在自己的项目里直接看实际依赖树，最准确也最直观。maven项目里执行：

mvn dependency:tree -Dverbose

如果只想看geotools相关的依赖路径，可以加上includes参数过滤：

mvn dependency:tree -Dincludes=org.geotools

还可以指定只看某个模块的具体依赖来源：

mvn dependency:tree -Dincludes=org.geotools:gt-shapefile

这个命令输出会清楚显示每个jar包的版本以及是谁传递依赖进来的。排查版本冲突时，-Dverbose参数会额外显示被忽略的依赖项，非常有用。我第一次用这个命令时，发现项目里同时存在两个不同版本的gt-main，就是靠它定位到的。

3. 收集所有jar包与离线环境部署

3.1 用dependency:copy-dependencies导出jar包

很多内网环境的服务器是无法访问外网仓库的，这时就需要在能联网的机器上把geotools 28.2相关依赖一次性收集齐全。maven自带的dependency插件就能干这件事，不需要额外装工具。

在项目根目录执行：

mvn dependency:copy-dependencies -DoutputDirectory=./lib -DincludeScope=runtime

执行完成后，项目下会出现一个lib目录，里面就是当前项目所有runtime级别的jar包，包括geotools的所有模块和它们传递依赖的第三方库。如果想连编译期依赖一起导出，把includeScope改成compile即可。

这里有个细节：直接拷贝lib目录虽然能让大部分Java命令跑起来，但它丢失了maven的依赖坐标信息。如果你是想把整套依赖搬到另一个maven项目里复用，更推荐的做法是直接复制本地仓库（.m2/repository）下相关目录。

3.2 离线环境从本地仓库迁移依赖

本地仓库迁移的思路很简单：在联网机器上先执行一次完整的mvn dependency:go-offline，让maven把所有依赖下载到本地仓库；然后把本地仓库打包，传到内网环境解压替换即可。

实操时，如果只针对geotools相关依赖，可以只复制.m2/repository/org/geotools目录、.m2/repository/org/locationtech/jts目录，再加上gt模块传递依赖的第三方库目录。但手工挑目录很容易漏，我建议直接执行：

mvn dependency:go-offline

这个命令会把当前项目涉及的所有插件和依赖一次性下载下来，本地仓库就齐了。之后把整个.m2目录打包带走，内网机器上配置好settings.xml指向这个仓库目录，离线构建基本没问题。

3.3 构建Nexus私服托管依赖

如果你的团队有多个项目都在用geotools，每次都靠拷贝.m2目录不是长久之计，配置一个Nexus私有仓库是更正规的方案。做法分两步。

第一步，在Nexus上创建一个maven2代理仓库，代理地址填OSGeo仓库：https://repo.osgeo.org/repository/release/，同时再创建一个代理仓库指向Maven中央仓库，两个仓库都加入同一个公开仓库组。

第二步，在项目的pom.xml中配置仓库地址指向私服，或者修改settings.xml统一管理：

<repositories> <repository> <id>my-nexus</id> <url>http://your-nexus-ip/repository/maven-public/</url> </repository> </repositories>

私服搭建之后，开发者不需要每个人都去联网拉geotools依赖，首次解析速度会快很多，版本也统一。另外提醒一句，Nexus的代理仓库默认有缓存策略，geotools发新版本后，如果拉不到最新jar，记得在Nexus后台执行一次“刷新缓存”或手动清理缓存。

4. 版本冲突排查与Spring Boot打包集成

4.1 高频冲突清单与排除方法

geotools和Spring Boot一起用，是我见过冲突最多的情况。整理几个最常见的版本冲突场景和对应处理办法。

JTS版本冲突是最典型的。Spring Boot本身并不直接依赖JTS，但项目里一旦用了其他空间库（比如Hibernate Spatial），就可能引入不同版本的jts-core。geotools 28.2要求JTS 1.19.0，如果你的项目里被拉进了1.18甚至更早的版本，运行时会报类似java.lang.NoSuchMethodError: org.locationtech.jts.geom.Geometry.xxx。解决办法是在pom.xml里显式声明：

<dependency> <groupId>org.locationtech.jts</groupId> <artifactId>jts-core</artifactId> <version>1.19.0</version> </dependency>

PostgreSQL驱动冲突也很常见。gt-postgis通过JDBC访问数据库，如果你的项目用的是Spring Boot的DataSource自动配置，postgresql驱动版本和数据库服务端不匹配时，表现是连接报错或者SQL语句解析失败。建议postgresql驱动统一用你连接的PostgreSQL主版本对应驱动。

还有一种容易忽略的是xerces冲突。geotools某些模块会依赖xercesImpl，而Java自带JAXP实现，两个解析器同时存在时会出现XML解析行为不一致。如果不是确有需要，可以把xercesImpl用exclusion排除掉，让geotools走JDK内置解析器。

4.2 打包时jar包冲突与META-INF/services合并

用Spring Boot的spring-boot-maven-plugin打包fat jar时，geotools有个很经典的坑：多个gt模块的jar包中都有META-INF/services目录下的SPI配置文件，如果这些配置没有正确合并，运行时会报“找不到某个GeoTools操作”，但编译期完全正常。

解决方案是给spring-boot-maven-plugin指定需要合并的路径：

<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <requiresUnpack> <dependency> <groupId>org.geotools</groupId> <artifactId>gt-main</artifactId> </dependency> </requiresUnpack> </configuration> </plugin>

requiresUnpack配置的作用是让Spring Boot启动时把指定jar解压到临时目录，避免嵌套jar场景下SPI文件加载失败。这个配置最好把你实际用到的所有gt-*模块都加上，尤其是gt-referencing、gt-shapefile这些。我在项目里第一次打包后运行报“Unable to find service”就是通过这个方式解决的。

如果用的不是Spring Boot，而是普通可执行jar，记得在打包时手动合并META-INF/services，否则同样会遇到类似问题。

4.3 使用mvn dependency:tree定位冲突源

版本冲突的排查思路其实很固定，就是先找到冲突jar包是从哪条路径传递进来的，再看是否值得排除。

执行：

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

输出里会看到类似这样的信息：

[INFO] +- org.geotools:gt-shapefile:jar:28.2:compile [INFO] +- org.geotools:gt-main:jar:28.2:compile [INFO] +- org.geotools:gt-referencing:jar:28.2:compile

如果同一坐标出现多个版本，说明存在冲突，可以定位到是哪个父级依赖带进来的。之后在父级依赖上加exclusion，去掉不需要的版本：

<exclusions> <exclusion> <groupId>org.geotools</groupId> <artifactId>gt-referencing</artifactId> </exclusion> </exclusions>

排除之后务必重新执行dependency:tree，确认最终生效的版本是你想要的那个。这个流程虽然简单，但我见过很多人一上来就直接排除坐标，结果把真正需要的模块也排掉了，越搞越乱。

5. 常见问题排查与避坑实录

5.1 典型问题速查表

5.2 值得记住的几个细节坑

先说本地仓库的.lastUpdated文件问题。maven下载依赖失败后，会在本地仓库生成以.lastUpdated结尾的临时文件，并且默认缓存一段时间。这个文件存在时，哪怕你修复了网络或仓库地址，maven依然不会重新下载。遇到“明明改好了还是报下载失败”的情况，优先排查这个文件。

再说Windows环境下打包geotools项目的一个坑：geotools依赖树很深，本地仓库路径如果很长，maven在拷贝文件名时会报“文件名或扩展名太长”。处理办法是修改maven的本地仓库路径为短目录，比如C:\m2repo，同时把项目路径也放到短路径下，这个问题基本就不会再出现。

还有一个我踩过的坑是IDEA里的maven仓库源顺序。IDEA的maven配置如果同时存在多个settings.xml和全局级仓库配置，可能导致geotools走的是中央仓库而不是OSGeo仓库，然后下载失败。排查时先把自定义settings.xml中的镜像配置简化，确认仓库源是否被镜像拦截。另外，如果你公司内网有统一maven镜像，但镜像没有同步OSGeo仓库，即使配置了私服也可能拉不到geotools构件，这时候要在镜像配置的mirrorOf里排除OSGeo仓库，或者确保镜像支持透传。

最后给一个实战小建议：geotools的依赖虽然复杂，但解决方案几乎都可以靠mvn dependency:tree和合理的exclusion策略搞定。不要看到一个冲突就直接排除，先搞清楚这个坐标是谁带进来的、被排除后会不会导致其他模块功能缺失。把依赖树看明白了，geotools 28.2的jar包管理一点都不神秘。

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