在 Ubuntu 上维护 JSP 项目时，最容易出问题的往往不是业务代码，而是依赖库版本、打包方式和部署目录。与其手动下载一堆 JAR 再逐个拷贝，不如从一开始就把依赖交给 Maven 或 Gradle 管理。下面按实际使用顺序梳理环境准备、两套主流方案以及手动管理的适用边界，方便你快速判断该怎么选、怎么配。
先准备 Java 环境
JSP 的编译和运行都依赖 JDK。Ubuntu 上建议先安装 OpenJDK 11 及以上版本，再继续后面的 Maven 或 Gradle 配置。
sudo apt update
sudo apt install openjdk-11-jdk
# 验证安装
java -version
# 应输出 Java 版本信息
javac -version # 应输出 Java 编译器版本信息如果这一步没有通过，后续的项目初始化、依赖下载和 WAR 打包都无法正常完成。
用 Maven 管理 JSP 依赖
如果你希望配置方式更成熟、资料更多，Maven 仍然是 JSP 项目里最常见的方案。它通过 pom.xml 统一声明依赖、插件和打包方式，适合大多数 Ubuntu 上的 Java Web 开发场景。
安装并验证 Maven
sudo apt update
sudo apt install maven
# 验证安装
mvn -version
# 应输出 Maven 版本信息创建带 JSP 支持的 Web 项目
可以直接使用 Maven 提供的 Web 项目骨架生成一个基础工程：
mvn archetype:generate -DgroupId=com.example -DartifactId=my-jsp-app -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false
cd my-jsp-app这样可以少做很多目录和基础配置的手工工作，适合作为 JSP 项目的起点。
在 pom.xml 中声明依赖和打包方式
JSP 项目通常至少要声明 Servlet API、JSP API，以及按需使用的 JSTL。这里最关键的是 provided 范围：表示这些库由 Tomcat 之类的 Servlet 容器在运行时提供，因此打包进 WAR 时不再重复带上，能减少冲突概率。
4.0.0
com.example
my-jsp-app
1.0-SNAPSHOT
war
UTF-8
11
11
javax.servlet
javax.servlet-api
4.0.1
provided
javax.servlet.jsp
javax.servlet.jsp-api
2.3.3
provided
javax.servlet
jstl
1.2
my-jsp-app
org.apache.tomcat.maven
tomcat7-maven-plugin
2.2
http://localhost:8080/manager/text
TomcatServer
/my-jsp-app
这里还有两个细节不要漏掉：
war - 如果要用 Maven Tomcat 插件直接部署，需要提前在
~/.m2/settings.xml配好 Tomcat 账号信息。
构建并部署 Maven 项目
- 下载依赖并编译项目：在项目根目录运行
mvn clean install，Maven 会自动下载pom.xml中声明的依赖，并把项目打包成target/my-jsp-app.war文件。 - 部署到 Tomcat：把生成的 WAR 文件复制到 Tomcat 的
webapps目录，比如/var/lib/tomcat9/webapps/，Tomcat 会自动解压并部署。 - 如果已经配置好 Tomcat Manager，也可以直接执行
mvn tomcat7:deploy完成部署。
用 Gradle 管理 JSP 依赖
如果你更习惯脚本化配置，Gradle 也能完成同样的工作。它与 Maven 的核心思路一致，区别主要在于配置文件从 pom.xml 换成了 build.gradle。
安装并验证 Gradle
sudo apt update
sudo apt install gradle
# 验证安装
gradle -version
# 应输出 Gradle 版本信息初始化 Gradle Web 项目
mkdir my-jsp-gradle-app
cd my-jsp-gradle-app
gradle init --type java-application
# 编辑build.gradle文件（见下文）原始初始化模板不是完整 JSP Web 工程，因此后面还要手动补上 war 插件和依赖配置。
在 build.gradle 中添加插件和依赖
plugins {
id 'java'
id 'war' // 必须添加War插件，用于生成WAR包
}
repositories {
mavenCentral() // 依赖仓库
}
dependencies {
// Servlet API（运行时由Tomcat提供）
providedCompile 'javax.servlet:javax.servlet-api:4.0.1'
// JSP API（运行时由Tomcat提供）
providedCompile 'javax.servlet.jsp:javax.servlet.jsp-api:2.3.3'
// JSTL（可选）
implementation 'javax.servlet:jstl:1.2'
}
// 配置War文件名
war {
archiveFileName = 'my-jsp-gradle-app.war'
}这套配置的关键点和 Maven 基本一致：Servlet API 与 JSP API 不应重复打进运行容器已经提供的环境中，而 WAR 插件决定了最终产物是否能被 Tomcat 直接部署。
构建并部署 Gradle 项目
- 下载依赖并编译项目：运行
gradle build，Gradle 会生成build/libs/my-jsp-gradle-app.war文件。 - 部署到 Tomcat：把 WAR 文件复制到 Tomcat 的
webapps目录，Tomcat 会自动部署。
什么时候才考虑手动管理 JAR
如果项目非常简单，或者只是临时验证一个 JSP 页面，也可以把依赖库手动复制到应用的 WEB-INF/lib 目录，例如 /var/lib/tomcat9/webapps/myapp/WEB-INF/lib/。
但这种方式的问题也很直接：
- 依赖版本全靠人工维护，容易遗漏或混用。
- 项目迁移时，很难快速还原完整依赖关系。
- 后续升级、排查冲突和多人协作成本都会明显增加。
因此，手动管理更适合临时场景，不适合作为长期维护方案。
实际使用时怎么选
如果你的目标是稳定、规范地维护 Ubuntu 上的 JSP 项目，优先选 Maven 通常最省事；如果团队本身已经在用 Gradle，也完全可以沿用。两者的共同原则其实只有两个：一是把依赖声明写进构建文件，二是明确哪些库由 Tomcat 这类容器提供，避免在 WAR 包里重复打包。
从长期维护角度看，只要脱离手动拷贝 JAR 的方式，JSP 依赖管理就已经进入了更可控的状态。
