Gradle打包含兄弟子项目依赖的Zip包问题（AWS Lambda部署）

看起来你遇到的核心问题是生成的Zip包只包含模块自身类，遗漏了依赖的类库模块以及其他第三方依赖——这在Gradle里是个很常见的情况，毕竟默认的jar任务只会打包当前模块的编译产物，不会自动收集所有依赖。下面给你两种靠谱的解决方案，完全适配你的多模块场景：

方案一：自定义Gradle任务手动收集依赖（无需第三方插件） #

如果不想引入额外插件，可以在每个业务模块的build.gradle里添加自定义的Zip任务，明确把依赖的JAR（包括你的类库模块和第三方依赖）打包进去：

// 每个依赖类库模块的业务模块中添加该配置
task buildLambdaZip(type: Zip) {
    // 打包当前模块编译后的类文件和资源文件
    from sourceSets.main.output.classesDirs
    from sourceSets.main.output.resourcesDir

    // 遍历收集所有runtime依赖（含你的类库模块+第三方库）
    configurations.runtimeClasspath.each { file ->
        if (file.isDirectory()) {
            from file
        } else {
            // 把依赖JAR解压后打包进Zip（Lambda不能加载嵌套JAR，必须平铺类文件）
            from zipTree(file)
        }
    }

    // 自定义Zip包的输出路径和名称
    archiveFileName = "${project.name}-lambda.zip"
    destinationDirectory = file("${buildDir}/distributions")
}

// 让build任务自动触发这个Zip打包任务
build.dependsOn buildLambdaZip

关键细节说明： #

• configurations.runtimeClasspath：这个配置集合包含了模块运行时需要的所有依赖，包括你已经声明的类库模块，以及所有第三方依赖包。
• from zipTree(file)：Lambda运行环境无法直接识别嵌套在Zip里的JAR文件，所以必须把依赖JAR里的类文件解压后，和当前模块的类放在同一层级。

方案二：使用Shadow插件（更简洁，推荐） #

Gradle的Shadow插件专门用来生成包含所有依赖的"胖包"，不管是JAR还是Zip格式都支持，配置起来更省心，还能自动处理重复类、合并META-INF资源等问题，非常适合Lambda部署场景。

步骤1：在根项目的settings.gradle中配置插件仓库（如果未添加） #

pluginManagement {
    repositories {
        gradlePluginPortal()
        mavenCentral()
    }
}

步骤2：在每个业务模块的build.gradle里应用Shadow插件并配置 #

plugins {
    id 'java'
    id 'com.github.johnrengelman.shadow' version '8.1.1' // 可替换为最新版本
}

// 配置Shadow任务生成Zip格式包
shadowJar {
    // 指定输出格式为Zip
    archiveExtension.set('zip')
    // 自动合并服务提供者等META-INF资源，避免Lambda运行时找不到实现类
    mergeServiceFiles()
    // 自定义Zip包名称
    archiveFileName = "${project.name}-lambda.zip"
}

// 让build任务自动触发Shadow打包
build.dependsOn shadowJar

为什么更推荐这个方案？ #

• Shadow插件会自动处理依赖的传递性，不需要手动遍历配置集合，减少出错概率。
• 内置了依赖排除、重复类处理等功能，可以轻松精简Zip包大小。
• 自动合并META-INF目录下的配置文件，避免出现服务加载失败的问题。

验证要点 #

不管用哪种方案，生成Zip后可以解压检查：

• 根目录下应该有所有模块的类文件（包括你的类库模块的类）
• 第三方依赖的类文件也在对应包路径下
• 没有嵌套的JAR文件（如果用Lambda层的话另说，但这里是把运行时必需的所有类都平铺在一个Zip里）

另外，务必确认每个业务模块都正确声明了对类库模块的依赖，比如：

dependencies {
    implementation project(':your-library-module') // 替换为你的类库模块名称
    // 其他第三方依赖
}

内容的提问来源于stack exchange，提问作者balsick