Eclipse跨Fragment测试用共享工具类的非生产依赖方案咨询

该实现方式完全可行，是Eclipse插件工程体系下隔离测试侧依赖的标准落地路径，可从构建、类加载、部署三个层面完全保证测试工具类不会进入生产范畴

• Eclipse PDE与OSGi类加载机制天然支持细粒度的Bundle依赖隔离，只要通过配置明确模块的加载边界，完全可以做到生产环境对测试工具类零感知
• 主流的Eclipse插件构建工具（Tycho、bnd）都支持分Profile的模块聚合、打包规则，无需额外自定义复杂逻辑就能区分生产构建和测试构建的范围

按照职责拆分三个独立的模块层级，每层严格限定依赖方向，杜绝反向依赖：

• 生产业务插件层：承载所有对外提供正式功能的生产代码，模块元数据中不声明任何测试侧模块的依赖，生产构建时是唯一的打包、部署对象，完全感知不到测试模块的存在
• 测试通用工具层：创建独立的Eclipse插件项目承载所有跨测试Fragment复用的工具类，命名上增加明确的测试标识（比如com.yourorg.eclipse.testsuite.util），从模块命名上就和生产模块做物理隔离：
  • 该模块不注册任何Eclipse扩展点、OSGi服务，不会对生产功能产生任何运行时影响
  • 模块元数据中增加自定义标识属性（比如X-Test-Only: true），方便构建流水线和运行时做自动识别
  • 构建配置中明确将该模块排除在生产聚合构建的清单外，生产打包流程不会把该模块的产物纳入发布包

  不要图省事把测试工具类放到生产插件的src/test目录下，这类路径下的类很容易因为构建配置疏漏被打包到生产Jar里，单独拆独立测试插件是长期维护成本最低的方案。

• 测试Fragment层：原有的功能验证测试Fragment本身就是仅测试场景生效的组件，直接声明对上述测试通用工具插件的依赖即可，不需要各自重复实现通用测试逻辑

为了从流程上杜绝测试类误入生产的可能，需要配套落地三层校验：

• 构建阶段校验：生产构建任务启动时，扫描所有纳入生产范围的插件依赖清单，一旦发现生产插件引入了测试通用工具插件、测试Fragment的依赖，直接触发构建失败
• 制品流转校验：测试通用工具插件、测试Fragment的构建产物仅推送至内部测试制品仓库，不进入生产环境的正式制品存储链路
• 运行时校验：生产环境的Eclipse启动配置中，增加对带X-Test-Only标识Bundle的自动过滤规则，就算出现人为拷贝的操作失误，测试类Bundle也不会被OSGi容器加载

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