Helidon项目日志依赖管理优化：移除核心模块对Logback的依赖声明

背景与问题分析

在Helidon 4.x版本的核心构建文件中，dependencies/pom.xml意外地包含了Logback日志框架的依赖管理信息。这是一个需要优化的设计问题，因为：

1. 架构清晰性：Helidon核心组件本身并不直接依赖Logback框架，这种声明属于非必要的依赖暴露
2. 职责分离：日志实现的选择应该属于应用层决策，框架核心只需提供标准接口支持
3. 依赖污染：核心POM中声明的依赖会全局影响所有子模块，可能造成不必要的传递依赖

技术影响评估

虽然Logback是Java生态中广泛使用的SLF4J实现，但将其从核心依赖管理移除时需要考虑：

1. 向后兼容性：现有用户可能隐式依赖Helidon的依赖管理来控制Logback版本
2. 示例项目适配：需要为使用Logback的示例项目（如logging-slf4j示例）建立新的依赖管理机制
3. 原生镜像支持：SLF4J模块中仍包含以字符串形式声明的Logback原生镜像配置，这些需要保留

解决方案设计

建议采用以下改进方案：

1. 核心清理：

   • 从dependencies/pom.xml完全移除Logback相关依赖声明
   • 保留SLF4J接口的依赖管理（属于日志标准）

2. 示例项目调整：

   • 在examples代码库中单独管理Logback依赖
   • 为示例项目建立适当的依赖管理POM

3. 版本策略：

   • 在次要版本中实施此变更（非破坏性变更）
   • 更新升级指南说明此调整

实施建议

对于开发者升级到新版本时：

1. 显式声明：需要自行在项目中声明Logback依赖
2. 版本控制：建议使用Bill of Materials(BOM)或直接指定稳定版本
3. 测试验证：特别注意日志输出和原生镜像构建的验证

最佳实践

基于此变更，推荐以下日志配置实践：

1. 灵活选择：根据项目需求自由选择Logback、Log4j2等SLF4J实现
2. 显式配置：在应用POM中明确声明日志实现依赖
3. 模块化设计：将日志配置隔离在特定功能模块中

此改进将使Helidon的日志架构更加清晰，同时给予开发者更大的灵活性和控制权。