AI导哈

Java应用现代化框架

一个多代理模型上下文协议（MCP）框架，用于自动化将遗留Java 8应用程序升级到Java 17，转换为Spring Boot 3.x微服务架构，并准备云部署。

  • by raunak220191
  • 本地部署
  • 更新于
在 GitHub 查看 raunak220191/mcp_migration

使用说明

MCP迁移框架

用于自动化Java应用程序现代化的多代理模型上下文协议（MCP）框架。该框架协调了遗留Java 8应用程序到Java 17的迁移，将单片架构转换为Spring Boot 3.x微服务，并为云部署准备应用程序。

概述

该框架使用协调的多代理方法，其中每个代理在迁移管道中都有特定的职责：

代理 角色 描述
代理人1 Repository Analyzer 分析遗留代码库并创建全面的迁移计划
代理人2 Java 17提升引擎 通过全面的现代化将Java 8代码转换为Java 17语法和API（集合、试用资源、记录、密封类、模式匹配、不推荐使用的API替换、Gradle迁移）
代理人3 微服务转换器 转换为Spring Boot 3.x微服务架构
代理人4 一致性验证器 验证结构的正确性和完整性
代理人5 云就绪构建器 使用Docker和Kubernetes配置为云部署做准备
大师 Orchestrator 监督所有代理并管理迁移状态

项目结构

mcp_migration/
├── README.md                  # This file
├── migration_state.json       # Tracks agent completion status
├── mcp/
│   └── mcp.json              # MCP configuration and tool definitions
└── agent_prompts/
    ├── MASTER.md             # Master orchestrator instructions
    ├── AGENT1_ANALYSIS.md    # Repository analysis agent
    ├── AGENT2_JAVA17.md      # Java 17 uplift agent
    ├── AGENT3_MICROSERVICE.md # Microservice conversion agent
    ├── AGENT4_CONSISTENCY.md  # Validation agent
    └── AGENT5_CLOUD_READY.md  # Cloud readiness agent

运作原理

迁移管道

  1. 分析阶段（代理1）

    • 扫描中的所有文件 legacy_repo/
    • 确定弃用的API、架构差距和迁移要求
    • 输出分析 migrated_code/docs/ANALYSIS_REPORT.md

  2. Java 17升级阶段（代理2）

    • 将代码从Java 8转换为Java 17，实现全面现代化
    • 应用现代Java特性：lambdas、流、记录、密封类、模式匹配、开关表达式、文本块、var关键字
    • 替换已弃用的API：日期/日历→ java.time，HttpURLConnection→ HttpClient，文件I/O→ 文件API
    • 使藏品现代化：Vector→ ArrayList，哈希表→ ConcurrentHashMap，不可变集合
    • 对所有可自动关闭的资源实施try with资源
    • 使用Java 17工具链将构建系统迁移到Gradle（不是Maven）
    • 输出到 migrated_code/lifting_java17/

  3. 微服务转换阶段（代理3）

    • 转换为Spring Boot 3.x架构
    • 创建控制器、服务、存储库和DTO
    • 输出到 migrated_code/microserviceized/

  4. 验证阶段（试剂4）

    • 验证包结构和依赖关系
    • 检查缺少的导入和循环依赖关系
    • 输出报告给 migrated_code/docs/CONSISTENCY_REPORT.md

  5. 云准备阶段（代理5）

    • 生成Dockerfile和docker-compose.yml
    • 创建Kubernetes部署清单
    • 输出到 migrated_code/cloud_ready/

状态管理

这 migration_state.json 文件跟踪每个代理的完成状态：

{
  "agent1_completed": false,
  "agent2_completed": false,
  "agent3_completed": false,
  "agent4_completed": false,
  "agent5_completed": false,
  "last_processed_file": null
}

这实现了可恢复性——如果迁移中断，它可以从最后一个完成的代理继续。

用法

先决条件

  • MCP兼容的AI助手或运行时
  • 遗留Java代码库 legacy_repo/ 目录

运行迁移

  1. 将您的旧Java代码放在 legacy_repo/ 目录
  2. 运行主代理(agent_prompts/MASTER.md)协调迁移
  3. 主代理人将：
    • 检查 migration_state.json 当前进展
    • 按顺序执行每个代理（1→5）
    • 每个代理完成后更新状态
    • 生成最终文档

输出结构

迁移完成后：

migrated_code/
├── lifting_java17/           # Java 17 uplifted code
├── microserviceized/         # Spring Boot 3.x microservices
├── cloud_ready/              # Cloud deployment configs
└── docs/
    ├── ANALYSIS_REPORT.md
    ├── JAVA17_UPLIFT_REPORT.md
    ├── MICROSERVICE_CONVERSION_REPORT.md
    ├── CONSISTENCY_REPORT.md
    ├── CLOUD_READY_REPORT.md
    ├── EXECUTIVE_SUMMARY.md
    ├── FULL_CHANGELOG.md
    └── MANUAL_REVIEW_STEPS.md

关键原则

  • 只读旧代码：原始源文件永远不会被修改
  • 业务逻辑保存：所有转换都保留现有的业务逻辑
  • 增量迁移：每个代理都基于前一个代理的输出构建
  • 综合文档：每个转换都有记录
  • 可恢复流程：可以使用状态跟踪从任何点恢复迁移

MCP配置

这 mcp/mcp.json 文件定义了代理可用的工具：

  • list_files -扫描目录
  • read_file -读取文件内容
  • write_file / create_file -创建输出文件
  • delete_file -删除文件
  • rename_file -移动/重命名文件
  • search -搜索文件内容
  • stat -获取文件元数据

许可证

有关详细信息，请参阅存储库许可证。

相关 MCP