Mockito项目结构调整：将核心代码迁移至专用目录

背景与现状分析

Mockito作为Java领域广泛使用的测试框架，其项目结构多年来一直保持着将核心代码直接存放在项目根目录下的传统模式。这种结构在当前项目规模下逐渐显现出一些不足之处：

1. 源码与子项目混杂：根目录下同时存在src/main/java和subprojects目录，这种混合布局对于新贡献者不够直观
2. 构建脚本复杂度高：根项目的Gradle构建脚本需要同时处理根项目、mockito-core以及各种子项目的配置
3. 与行业惯例不符：主流Java项目（如Spring、Micronaut等）普遍采用模块化目录结构

改进方案设计

经过社区讨论，计划将项目结构调整为更清晰的模块化布局：

├── mockito-core/        # 核心功能模块
├── mockito-extensions/  # 扩展模块
│   ├── bom/             # 物料清单
│   └── subclass-mockmacker/ # 特定功能扩展
└── mockito-integration-tests/ # 集成测试模块
    ├── ...
    └── java-21-tests/   # Java 21特定测试

技术实现考量

版本控制兼容性

文件迁移操作在Git中会被识别为"移动"而非"新建"，这可能会带来一些历史追溯的挑战。但现代工具已对此有良好支持：

• Git命令行可通过--follow参数追踪文件历史
• IntelliJ IDEA等IDE能自动关联文件重命名前后的变更历史
• GitHub平台已增强对文件移动历史的展示能力

构建系统适配

新的目录结构将带来Gradle配置的优化机会：

1. 各模块可以拥有独立的构建脚本
2. 根项目构建脚本只需关注公共配置和模块聚合
3. 依赖管理可以更加清晰地区分核心依赖和模块特定依赖

历史演进视角

值得注意的是，这并非Mockito项目第一次进行目录结构调整。在项目从SVN迁移到Mercurial再到Git的演进过程中，源码目录也经历过从src到src/main/java的转变。这种持续演进体现了项目对工程实践优化的不懈追求。

预期收益

1. 降低贡献门槛：清晰的模块划分使新贡献者更容易理解项目架构
2. 提升维护效率：分离的构建配置减少了意外耦合的风险
3. 符合现代实践：与主流Java项目结构保持一致，便于开发者跨项目协作
4. 增强可扩展性：为未来可能的模块拆分或新增提供更好的基础架构

实施建议

对于计划参与Mockito贡献的开发者，建议：

1. 关注项目结构变更的PR，了解新的目录布局
2. 使用支持文件历史追踪的IDE或Git工具
3. 在开发新功能时，按照新的模块划分原则选择适当的存放位置
4. 构建自定义模块时，参考现有子项目的配置方式

这次结构调整是Mockito项目持续优化其工程实践的重要一步，将为项目的长期健康发展奠定更好的基础架构。