如果你维护过几个基于Eclipse RCP的桌面客户端大概能体会那种“所有功能挤在一个主程序里”的酸爽。前阵子我们团队内部启动了一个代号Eclipse Core的插件项目目标是把一套已经跑了三年的桌面客户端做一次“核心能力抽离”。别看名字里带Eclipse它并不是在讲Eclipse IDE本身而是我们在RCP产品里单独抽出来的公共插件集合。这篇内容会把Eclipse Core的定位、设计、落地过程和踩坑实录原原本本说一遍希望给同样被老代码拖累的开发者一点参考。1. 项目定位与整体设计思路1.1 从主程序臃肿说起老项目早期的迭代策略很简单快速加功能先跑起来再说。于是登录、工作台、报表、定时任务、导入导出这些模块全部堆在一个主插件里表面上是一个插件实际内部已经像一盘散沙。静态类到处互相调用工具方法散落在不同包一个报表模块想升级第三方库结果发现不知道还有谁在偷偷用旧版本。整个团队连续三周都在和“改一处崩一片”作斗争。当时最直观的问题发生在启动环节。开发模式下启动一次大约要四十秒生产环境的打包体量已经超过了两百兆。每次提交代码哪怕只是改了一个查询条件构建机器也要把完整产品重新跑一遍出来一个安装包需要四十分钟。最难受的不是时间长而是无法做局部验证想单独跑一个报表插件必须把整个桌面应用都带起来。我当时的判断是不能再往这个主程序里塞东西了必须把公共能力和业务逻辑分开。1.2 插件化方案为什么是最优解那时候团队内部讨论过三个方案。第一个是重写一个单体应用把界面和技术栈整体换掉。这个方案看起来干净但从头写一个成熟桌面客户的成本至少是两到三个月而且业务逻辑重写一遍等于把旧坑又踩一次。第二个方案是把服务端拆成微服务桌面端只做展示。但现实环境里很多客户要求离线内网部署机器之间的通信条件不稳定微服务在桌面端完全不落地。第三个方案就是基于Eclipse RCP的插件化重构。Eclipse RCP底层是OSGi天生支持模块化、动态安装和卸载。我们可以把稳定不变的公共能力抽成一个核心插件集也就是Eclipse Core让外围业务插件依赖这个核心来运行。Eclipse Core并不是一个神秘组件它本质上是我们团队对不同模块命名的集合公共接口、数据源管理、用户会话、日志埋点、扩展点注册等。选这个方案的原因很直接不用更换现有技术栈不需要推倒重来只需要重新划分依赖边界原有业务代码可以一层层挪进独立插件里。1.3 四个必须解掉的痛点动手之前我们列了一个内部专项单整张表只解决四件事痛点典型表现Eclipse Core的应对数据库连接混乱每个插件各自建连接池高峰时连接数直接打爆核心统一维护数据源业务插件只从服务中获取连接用户会话不统一登录信息散落在静态类跨模块传递各种ClassCastException核心维护会话上下文通过ThreadLocal和切面传递当前用户日志规范缺失一半插件用log4j一半用java.util.logging还有直接System.out核心提供统一日志接口内部适配到底层实现业务插件加载无序插件启动全靠启动顺序顺序一错就空指针核心定义扩展点与生命周期状态机按优先级和依赖关系加载这四个问题并不是靠某个“魔法框架”能解决的核心价值在于先立规矩再让所有业务插件按同一套协议执行。Eclipse Core承担的其实是基础设施角色它不关心具体业务逻辑只提供稳定可靠的底座。2. 核心模块拆解与关键实现2.1 插件工程结构与依赖方向从仓库结构上我们把Eclipse Core分成了四个工程com.example.eclipsecore/ 主插件生命周期管理、扩展点注册、常量定义 com.example.eclipsecore.api/ 公共接口与数据模型BizModule、SessionContext、LogService com.example.eclipsecore.data/ 数据访问与连接池统一数据源、事务管理 com.example.eclipsecore.ui/ 通用UI组件消息框、进度条、折线图组件、主题变量依赖方向是单向的业务插件只能依赖com.example.eclipsecore.api和com.example.eclipsecore.ui不能反向依赖com.example.eclipsecore.data的内部实现。data工程会暴露服务给api使用但业务插件拿到的仅仅是接口不持有任何具体实现类。这样做有一个直接的好处只要接口保持稳定核心内部随便调整业务插件都不需要跟着改。我们曾经把数据库连接池从C3P0换成HikariCP只改了data工程20多个业务插件一行代码都没动整个升级过程两天就完成了。如果当初业务插件都直接依赖具体连接池类这种升级根本不可能顺利落地。2.2 动态模块注册机制要让业务插件能“按需加入”Eclipse Core使用扩展点来完成动态注册。Eclipse扩展点的思路很像“带契约的插槽”核心定义好插槽的格式业务插件按格式往里塞内容核心代码在运行时发现这些内容并加载。首先在核心插件plugin.xml里声明一个扩展点extension-point idbusinessModule nameBusiness Module schemaschema/businessModule.exsd/对应地写一个简单schema要求业务方提供名称和实现类complexType namemoduleSpec attribute namename typestring userequired/ attribute nameclass typestring userequired/ /complexType业务插件在自己的plugin.xml中通过扩展点声明业务模块extension pointcom.example.eclipsecore.businessModule businessModule nameorderReport classcom.example.biz.report.OrderReportModule/ /extension核心的加载器在启动阶段扫描扩展点并实例化public void loadModules() { IExtensionRegistry registry RegistryFactory.getRegistry(); IExtensionPoint point registry.getExtensionPoint( com.example.eclipsecore.businessModule); if (point null) { return; } for (IExtension extension : point.getExtensions()) { for (IConfigurationElement element : extension.getConfigurationElements()) { String name element.getAttribute(name); IBusinessModule module (IBusinessModule) element .createExecutableExtension(class); module.initialize(createModuleContext()); modules.put(name, module); } } }createExecutableExtension会根据配置的类名在当前扩展点所属插件里完成类加载和实例化。这样新增业务模块时不用改动核心代码只需要增加一个插件并声明扩展点。这个机制让团队可以并行开发有人负责业务插件注册有人负责核心加载逻辑两边只需遵守同一个schema约定。2.3 统一数据源与会话管理老系统里每个业务插件都自己写一个DBHelper看起来很独立实际互相之间根本不知道对方的连接池配置。数据库连接数经常超限DBA隔三差五来问“是不是有连接泄漏”。重构后的Eclipse Core使用一张全局数据源表统一管理连接池核心把DataSource封装成OSGi服务在插件Activator启动时注册BundleContext context getContext(); DataSource ds createDataSource(loadConfig()); DataSourceService service new DataSourceServiceImpl(ds); context.registerService(DataSourceService.class.getName(), service, null);业务插件需要数据库操作时只从服务引用中拿连接Reference private DataSourceService dataSourceService; Connection conn dataSourceService.getConnection();只要会话上下文是绑在同一个业务操作里的切面切进去之后整个调用链都能拿到同一个用户。调试的时候我只需要看一个地方切面是否正确在进入服务方法时设置了Context又在返回时清空。只要这两点不出错线程池里即使复用线程也不会出现上一个用户的Session信息串到下一个请求里的诡异问题。2.4 日志规范与性能埋点Eclipse Core的日志接口只定义了两个动作记录普通日志、记录性能指标。底层实现可以随时替换今天可以输出到文件明天换成内网日志采集器业务插件代码完全不用变。我们在核心中做了个轻量的性能埋点工具public final class Tracer implements AutoCloseable { private final String operation; private final long start; public static Tracer start(String operation) { return new Tracer(operation); } private Tracer(String operation) { this.operation operation; this.start System.currentTimeMillis(); } Override public void close() { long cost System.currentTimeMillis() - start; LogHolder.get().info(operation cost cost ms); } }业务代码里使用它非常自然try (Tracer ignored Tracer.start(OrderReport.export)) { // 导出逻辑 }这个设计看起来简单却让团队第一次有了统一的性能监控能力。后来排查长时间卡顿的问题只靠日志里的“cost”字段就能初步判断是数据库慢还是计算慢不必每次都在汇报现场抓头皮了。3. 从零搭建Eclipse Core的实操复盘3.1 准备PDE目标平台和插件工程搭Eclipse Core之前先把基础环境准备好。我们用的是Eclipse同时自带的PDE环境新建工程时选择“Plug-in Project”。目标平台我习惯选“OSGi Framework”加一个Equinox runtime不要选Eclipse IDE本身的完整SDK因为那样会把大量用不到的UI包拉进来目标平台会变得特别沉。BREE建议直接选JDK 17或更高。如果团队还在用JDK 8至少也要选一个明确的版本不要选“default”让构建机器去猜。创建完插件工程后马上在MANIFEST.MF里看一眼Bundle-SymbolicName通常会把工程名设成插件名。这里的关键是命名要清晰com.example.eclipsecore.api一眼就知道是接口包com.example.eclipsecore.data一眼就知道是数据服务后续扫描依赖的时候非常省心。3.2 定义扩展点并编写核心加载器这一步是整个项目的关键节点。定义扩展点不只是写一段XMLschema往往才是最容易出错的地方。建议先在schema目录下新建一个.exsd文件然后只保留你需要的最小属性。我的做法是先定义name、class、order三个字段其中order用来控制加载顺序后续要用再继续加字段。写完schema以后在plugin.xml的extension-point中引用它。加载器核心代码我上面给过但这里要强调一个细节RegistryFactory.getRegistry()返回的是工作区级别的注册表在IDE调试时它会加载当前运行平台里所有已安装插件的扩展点。如果你在plugin.xml里写的扩展点ID和某个已存在插件重复就会导致注册表找不到你想要的那个点排查起来特别费劲。所以开发时一定要给扩展点ID加上完整的插件名前缀避免全局冲突。加载完成后业务插件侧也要做一个简单的注册动作把自己的业务模块类作为扩展点元素贡献出来。整个过程没有用到反射去猜测类名也没有维护任何手动列表新增模块时只需要复制一个块。3.3 Import-Package还是Require-Bundle这是每个OSGi插件项目都会遇到的选择Eclipse Core同样绕不开。简单说Require-Bundle是整个插件级别的依赖粗暴但直观Import-Package是包级别的依赖支持版本范围更贴近模块化原则。对比维度Require-BundleImport-Package粒度一个插件里所有导出的包全部可见只加载你需要的那个包版本控制在Bundle整体上控制版本可以精确到包的版本范围循环依赖容易出现插件间耦合更依赖包名规划调试复杂性依赖关系清晰但范围大需要维护包导出列表我们在Eclipse Core内部坚持用Import-Package并且每个包都写上版本范围。比如业务插件引用核心接口时MANIFEST.MF中这样写Import-Package: com.example.eclipsecore.api;version[1.0,2.0), org.slf4j;version1.7.30这样当Eclipse Core升级到2.0版本并且有破坏性改动时旧业务插件不会因为无意中加载了新接口而炸掉版本范围会成为一道保护网。代价是每加一个新依赖都要检查导出包是否正确构建失败时错误信息也可能比Require-Bundle更绕。几次踩坑之后我养成了一个习惯改一次依赖就立刻执行一次mvn clean verify不要让错误信息过夜。3.4 用Tycho构建多插件产品Eclipse RCP项目开发时能在IDE里跑但在生产环境必须能自动构建。Tycho是Maven生态下的标准方案它把Eclipse的plugin.xml、MANIFEST.MF和feature这些文件纳入构建流程。我们核心工程里的pom.xml大概这样配packagingeclipse-plugin/packaging properties tycho.version4.0.0/tycho.version /properties build plugins plugin groupIdorg.eclipse.tycho/groupId artifactIdtycho-maven-plugin/artifactId version${tycho.version}/version extensionstrue/extensions /plugin /plugins /build如果是一个多聚合工程的根pom还需要指定子模块和p2 repository。构建机上跑mvn clean verify时Tycho会解析所有插件的依赖并生成最终的P2仓库或安装包。实际操作中最大的坑是p2仓库地址失效目标平台里的某个包版本在网上找不到了构建直接失败。这个要根据正式环境配置稳定可访问的p2仓库同时把target platform做成一个单独的工程固定版本提交到版本库这样构建机的环境就不会因为时间推移而漂移。4. 常见问题与排查技巧实录4.1 插件启动顺序错误导致的空指针第一次把Eclipse Core接入老产品时我们遇到了经典的启动空指针核心插件的数据源服务还没有注册业务插件就已经初始化完毕结果Reference注入进去的服务是null。这个问题的根源是查询启动顺序时各插件默认的Bundle-ActivationPolicy都是lazy真正激活的实际顺序不受代码控制。解决方案不是靠调整start level硬碰硬而是改用OSGi Declarative Services。将数据源服务、会话服务、日志服务全部声明成DS组件后业务插件只需要通过Reference来注入依赖Reference private SessionService sessionService;DS框架会保证在调用业务插件方法前依赖的服务已经就绪。这个改动从根上消灭了启动顺序战争。后来我们还在核心维护了一个StartupOrder常量类只在真正需要物理顺序的场景使用其他一律交给DS管理。4.2 扩展点加载不到业务模块某次在add新报表插件时Eclipse Core一直加载不到这个模块报错信息是ClassNotFoundException但是类的全名和包名都核对过没问题。最后定位到问题出在扩展点定义的元素名业务插件在plugin.xml中写的元素名和schema里定义的不一致导致解析器忽略了这个节点。排查这类问题时我通常按三步走第一步确认业务插件是否已经安装到运行实例里打开OSGi Console输入ss查看插件状态第二步检查扩展点ID拼写尤其是符号名前的插件前缀第三步在加载器代码里临时打印注册表拿到的所有元素名看能不能看到目标。只要三步都走一遍八成能定位问题。4.3 类加载冲突与重复库问题Eclipse Core内部统一使用POI做报表导出后业务插件很快就出现了NoClassDefFoundError。原因是一个旧插件把自己的poi.jar也放进了Bundle-ClassPath运行时每个插件都加载了自己的POI库Eclipse Core提供的服务返回的结果类型却来自另一个类加载器两边直接不匹配。这个问题在OSGi环境里非常典型。解决方法是把POI从所有业务插件的私有依赖中清除改成通过Eclipse Core统一提供并在导出包里显式声明Export-Package: org.apache.poi.ss.usermodel;version5.2.3, org.apache.poi.xssf.usermodel;version5.2.3业务插件通过Import-Package引用这些包。虽然改依赖的时候十几个插件都动了一下但之后报表相关模块完全不再出现类冲突。这也印证了一个原则公共第三方库放在核心层统一管理比每个业务插件各带一份要可靠得多。4.4 热部署失效与调试技巧开发Eclipse插件时代码热部署一直是让人又爱又恨的体验。有时候改了核心插件的逻辑保存后没生效界面上还是老行为。原因是Eclipse的运行时缓存里保存了旧的类定义扩展点这种静态配置更是被提前加载过动态刷新并不彻底。我的经验是改方法体时用Workbench自带的Hot Code Replace往往有效但改类的结构、加方法、改字段或者动了plugin.xml就必须重启应用。如果长时间调试时出现诡异状态直接停止运行配置然后再启动并加上启动参数-Dosgi.cleantrue这个参数会清掉OSGi运行时缓存强制重新解析所有插件。代价是启动时间会变长但保证了一个干净的环境。后来我们还配合Eclipse的“自动构建”功能和Tycho nightly构建每天凌晨生成一次最新插件包开发机直接从镜像库拉取比手工重建稳定很多。4.5 问题排查速查表整理一个开发过程中最有用的排查清单碰到问题可以直接对照现象可能原因解决方案服务引用为null插件启动顺序错误改用Declarative Services的Reference扩展点加载不到元素名/schema不一致比对plugin.xml和exsd中的名称ClassNotFoundError依赖包没有导出或导入检查Export-Package和Import-PackageNoClassDefFoundError同一个类被多个插件引入公共库统一由核心提供修改代码后不生效OSGi运行时缓存重启并加-Dosgi.cleantrue依赖无法解析p2仓库版本冲突固定目标平台版本内网保存镜像这张表后来直接放进了团队内部的Wiki新同学看一遍就能上手排查环境类问题效率提升非常明显。5. 如果再做一次Eclipse Core我会这样调整5.1 核心要薄扩展点要稳第一次设计时我一度想把所有“看起来公共”的东西全部放进Eclipse Core包括报表模板引擎、通用查询面板、权限判断工具。结果核心包越来越大版本升级时外围插件全部跟着遭殃。后来才想明白Eclipse Core不是一个收纳盒它应该像一个插座只提供最稳定的接口和最基础的运行机制具体业务引擎仍然放在业务插件里。核心真的做到足够薄后续扩展才好做。5.2 先定协议再写实现我们初期的最大教训是接口协议改得太频繁。今天觉得SessionContext里只需要用户名明天又要加部门权限后天还想塞IP地址。每次改动都触碰所有业务插件导致团队内部不断重复编译。后来调整了协作方式核心的重任在于先和业务插件开发者一起把扩展点的schema定下来再动手写实现代码。schema就好比一个契约契约稳定了核心代码怎么改都不易影响别人。最后分享一个小技巧每周做一次完整构建把所有插件的新版本和Eclipse Core一起编一遍任何依赖问题都会在第一时间暴露出来。早期我们总想着“下次一起构建”结果往往是在发布前三天连续加班。把构建动作固定成例行步骤之后才真正体会到“小步快跑”的好处。
如果你维护过几个基于Eclipse RCP的桌面客户端大概能体会那种“所有功能挤在一个主程序里”的酸爽。前阵子我们团队内部启动了一个代号Eclipse Core的插件项目目标是把一套已经跑了三年的桌面客户端做一次“核心能力抽离”。别看名字里带Eclipse它并不是在讲Eclipse IDE本身而是我们在RCP产品里单独抽出来的公共插件集合。这篇内容会把Eclipse Core的定位、设计、落地过程和踩坑实录原原本本说一遍希望给同样被老代码拖累的开发者一点参考。1. 项目定位与整体设计思路1.1 从主程序臃肿说起老项目早期的迭代策略很简单快速加功能先跑起来再说。于是登录、工作台、报表、定时任务、导入导出这些模块全部堆在一个主插件里表面上是一个插件实际内部已经像一盘散沙。静态类到处互相调用工具方法散落在不同包一个报表模块想升级第三方库结果发现不知道还有谁在偷偷用旧版本。整个团队连续三周都在和“改一处崩一片”作斗争。当时最直观的问题发生在启动环节。开发模式下启动一次大约要四十秒生产环境的打包体量已经超过了两百兆。每次提交代码哪怕只是改了一个查询条件构建机器也要把完整产品重新跑一遍出来一个安装包需要四十分钟。最难受的不是时间长而是无法做局部验证想单独跑一个报表插件必须把整个桌面应用都带起来。我当时的判断是不能再往这个主程序里塞东西了必须把公共能力和业务逻辑分开。1.2 插件化方案为什么是最优解那时候团队内部讨论过三个方案。第一个是重写一个单体应用把界面和技术栈整体换掉。这个方案看起来干净但从头写一个成熟桌面客户的成本至少是两到三个月而且业务逻辑重写一遍等于把旧坑又踩一次。第二个方案是把服务端拆成微服务桌面端只做展示。但现实环境里很多客户要求离线内网部署机器之间的通信条件不稳定微服务在桌面端完全不落地。第三个方案就是基于Eclipse RCP的插件化重构。Eclipse RCP底层是OSGi天生支持模块化、动态安装和卸载。我们可以把稳定不变的公共能力抽成一个核心插件集也就是Eclipse Core让外围业务插件依赖这个核心来运行。Eclipse Core并不是一个神秘组件它本质上是我们团队对不同模块命名的集合公共接口、数据源管理、用户会话、日志埋点、扩展点注册等。选这个方案的原因很直接不用更换现有技术栈不需要推倒重来只需要重新划分依赖边界原有业务代码可以一层层挪进独立插件里。1.3 四个必须解掉的痛点动手之前我们列了一个内部专项单整张表只解决四件事痛点典型表现Eclipse Core的应对数据库连接混乱每个插件各自建连接池高峰时连接数直接打爆核心统一维护数据源业务插件只从服务中获取连接用户会话不统一登录信息散落在静态类跨模块传递各种ClassCastException核心维护会话上下文通过ThreadLocal和切面传递当前用户日志规范缺失一半插件用log4j一半用java.util.logging还有直接System.out核心提供统一日志接口内部适配到底层实现业务插件加载无序插件启动全靠启动顺序顺序一错就空指针核心定义扩展点与生命周期状态机按优先级和依赖关系加载这四个问题并不是靠某个“魔法框架”能解决的核心价值在于先立规矩再让所有业务插件按同一套协议执行。Eclipse Core承担的其实是基础设施角色它不关心具体业务逻辑只提供稳定可靠的底座。2. 核心模块拆解与关键实现2.1 插件工程结构与依赖方向从仓库结构上我们把Eclipse Core分成了四个工程com.example.eclipsecore/ 主插件生命周期管理、扩展点注册、常量定义 com.example.eclipsecore.api/ 公共接口与数据模型BizModule、SessionContext、LogService com.example.eclipsecore.data/ 数据访问与连接池统一数据源、事务管理 com.example.eclipsecore.ui/ 通用UI组件消息框、进度条、折线图组件、主题变量依赖方向是单向的业务插件只能依赖com.example.eclipsecore.api和com.example.eclipsecore.ui不能反向依赖com.example.eclipsecore.data的内部实现。data工程会暴露服务给api使用但业务插件拿到的仅仅是接口不持有任何具体实现类。这样做有一个直接的好处只要接口保持稳定核心内部随便调整业务插件都不需要跟着改。我们曾经把数据库连接池从C3P0换成HikariCP只改了data工程20多个业务插件一行代码都没动整个升级过程两天就完成了。如果当初业务插件都直接依赖具体连接池类这种升级根本不可能顺利落地。2.2 动态模块注册机制要让业务插件能“按需加入”Eclipse Core使用扩展点来完成动态注册。Eclipse扩展点的思路很像“带契约的插槽”核心定义好插槽的格式业务插件按格式往里塞内容核心代码在运行时发现这些内容并加载。首先在核心插件plugin.xml里声明一个扩展点extension-point idbusinessModule nameBusiness Module schemaschema/businessModule.exsd/对应地写一个简单schema要求业务方提供名称和实现类complexType namemoduleSpec attribute namename typestring userequired/ attribute nameclass typestring userequired/ /complexType业务插件在自己的plugin.xml中通过扩展点声明业务模块extension pointcom.example.eclipsecore.businessModule businessModule nameorderReport classcom.example.biz.report.OrderReportModule/ /extension核心的加载器在启动阶段扫描扩展点并实例化public void loadModules() { IExtensionRegistry registry RegistryFactory.getRegistry(); IExtensionPoint point registry.getExtensionPoint( com.example.eclipsecore.businessModule); if (point null) { return; } for (IExtension extension : point.getExtensions()) { for (IConfigurationElement element : extension.getConfigurationElements()) { String name element.getAttribute(name); IBusinessModule module (IBusinessModule) element .createExecutableExtension(class); module.initialize(createModuleContext()); modules.put(name, module); } } }createExecutableExtension会根据配置的类名在当前扩展点所属插件里完成类加载和实例化。这样新增业务模块时不用改动核心代码只需要增加一个插件并声明扩展点。这个机制让团队可以并行开发有人负责业务插件注册有人负责核心加载逻辑两边只需遵守同一个schema约定。2.3 统一数据源与会话管理老系统里每个业务插件都自己写一个DBHelper看起来很独立实际互相之间根本不知道对方的连接池配置。数据库连接数经常超限DBA隔三差五来问“是不是有连接泄漏”。重构后的Eclipse Core使用一张全局数据源表统一管理连接池核心把DataSource封装成OSGi服务在插件Activator启动时注册BundleContext context getContext(); DataSource ds createDataSource(loadConfig()); DataSourceService service new DataSourceServiceImpl(ds); context.registerService(DataSourceService.class.getName(), service, null);业务插件需要数据库操作时只从服务引用中拿连接Reference private DataSourceService dataSourceService; Connection conn dataSourceService.getConnection();只要会话上下文是绑在同一个业务操作里的切面切进去之后整个调用链都能拿到同一个用户。调试的时候我只需要看一个地方切面是否正确在进入服务方法时设置了Context又在返回时清空。只要这两点不出错线程池里即使复用线程也不会出现上一个用户的Session信息串到下一个请求里的诡异问题。2.4 日志规范与性能埋点Eclipse Core的日志接口只定义了两个动作记录普通日志、记录性能指标。底层实现可以随时替换今天可以输出到文件明天换成内网日志采集器业务插件代码完全不用变。我们在核心中做了个轻量的性能埋点工具public final class Tracer implements AutoCloseable { private final String operation; private final long start; public static Tracer start(String operation) { return new Tracer(operation); } private Tracer(String operation) { this.operation operation; this.start System.currentTimeMillis(); } Override public void close() { long cost System.currentTimeMillis() - start; LogHolder.get().info(operation cost cost ms); } }业务代码里使用它非常自然try (Tracer ignored Tracer.start(OrderReport.export)) { // 导出逻辑 }这个设计看起来简单却让团队第一次有了统一的性能监控能力。后来排查长时间卡顿的问题只靠日志里的“cost”字段就能初步判断是数据库慢还是计算慢不必每次都在汇报现场抓头皮了。3. 从零搭建Eclipse Core的实操复盘3.1 准备PDE目标平台和插件工程搭Eclipse Core之前先把基础环境准备好。我们用的是Eclipse同时自带的PDE环境新建工程时选择“Plug-in Project”。目标平台我习惯选“OSGi Framework”加一个Equinox runtime不要选Eclipse IDE本身的完整SDK因为那样会把大量用不到的UI包拉进来目标平台会变得特别沉。BREE建议直接选JDK 17或更高。如果团队还在用JDK 8至少也要选一个明确的版本不要选“default”让构建机器去猜。创建完插件工程后马上在MANIFEST.MF里看一眼Bundle-SymbolicName通常会把工程名设成插件名。这里的关键是命名要清晰com.example.eclipsecore.api一眼就知道是接口包com.example.eclipsecore.data一眼就知道是数据服务后续扫描依赖的时候非常省心。3.2 定义扩展点并编写核心加载器这一步是整个项目的关键节点。定义扩展点不只是写一段XMLschema往往才是最容易出错的地方。建议先在schema目录下新建一个.exsd文件然后只保留你需要的最小属性。我的做法是先定义name、class、order三个字段其中order用来控制加载顺序后续要用再继续加字段。写完schema以后在plugin.xml的extension-point中引用它。加载器核心代码我上面给过但这里要强调一个细节RegistryFactory.getRegistry()返回的是工作区级别的注册表在IDE调试时它会加载当前运行平台里所有已安装插件的扩展点。如果你在plugin.xml里写的扩展点ID和某个已存在插件重复就会导致注册表找不到你想要的那个点排查起来特别费劲。所以开发时一定要给扩展点ID加上完整的插件名前缀避免全局冲突。加载完成后业务插件侧也要做一个简单的注册动作把自己的业务模块类作为扩展点元素贡献出来。整个过程没有用到反射去猜测类名也没有维护任何手动列表新增模块时只需要复制一个块。3.3 Import-Package还是Require-Bundle这是每个OSGi插件项目都会遇到的选择Eclipse Core同样绕不开。简单说Require-Bundle是整个插件级别的依赖粗暴但直观Import-Package是包级别的依赖支持版本范围更贴近模块化原则。对比维度Require-BundleImport-Package粒度一个插件里所有导出的包全部可见只加载你需要的那个包版本控制在Bundle整体上控制版本可以精确到包的版本范围循环依赖容易出现插件间耦合更依赖包名规划调试复杂性依赖关系清晰但范围大需要维护包导出列表我们在Eclipse Core内部坚持用Import-Package并且每个包都写上版本范围。比如业务插件引用核心接口时MANIFEST.MF中这样写Import-Package: com.example.eclipsecore.api;version[1.0,2.0), org.slf4j;version1.7.30这样当Eclipse Core升级到2.0版本并且有破坏性改动时旧业务插件不会因为无意中加载了新接口而炸掉版本范围会成为一道保护网。代价是每加一个新依赖都要检查导出包是否正确构建失败时错误信息也可能比Require-Bundle更绕。几次踩坑之后我养成了一个习惯改一次依赖就立刻执行一次mvn clean verify不要让错误信息过夜。3.4 用Tycho构建多插件产品Eclipse RCP项目开发时能在IDE里跑但在生产环境必须能自动构建。Tycho是Maven生态下的标准方案它把Eclipse的plugin.xml、MANIFEST.MF和feature这些文件纳入构建流程。我们核心工程里的pom.xml大概这样配packagingeclipse-plugin/packaging properties tycho.version4.0.0/tycho.version /properties build plugins plugin groupIdorg.eclipse.tycho/groupId artifactIdtycho-maven-plugin/artifactId version${tycho.version}/version extensionstrue/extensions /plugin /plugins /build如果是一个多聚合工程的根pom还需要指定子模块和p2 repository。构建机上跑mvn clean verify时Tycho会解析所有插件的依赖并生成最终的P2仓库或安装包。实际操作中最大的坑是p2仓库地址失效目标平台里的某个包版本在网上找不到了构建直接失败。这个要根据正式环境配置稳定可访问的p2仓库同时把target platform做成一个单独的工程固定版本提交到版本库这样构建机的环境就不会因为时间推移而漂移。4. 常见问题与排查技巧实录4.1 插件启动顺序错误导致的空指针第一次把Eclipse Core接入老产品时我们遇到了经典的启动空指针核心插件的数据源服务还没有注册业务插件就已经初始化完毕结果Reference注入进去的服务是null。这个问题的根源是查询启动顺序时各插件默认的Bundle-ActivationPolicy都是lazy真正激活的实际顺序不受代码控制。解决方案不是靠调整start level硬碰硬而是改用OSGi Declarative Services。将数据源服务、会话服务、日志服务全部声明成DS组件后业务插件只需要通过Reference来注入依赖Reference private SessionService sessionService;DS框架会保证在调用业务插件方法前依赖的服务已经就绪。这个改动从根上消灭了启动顺序战争。后来我们还在核心维护了一个StartupOrder常量类只在真正需要物理顺序的场景使用其他一律交给DS管理。4.2 扩展点加载不到业务模块某次在add新报表插件时Eclipse Core一直加载不到这个模块报错信息是ClassNotFoundException但是类的全名和包名都核对过没问题。最后定位到问题出在扩展点定义的元素名业务插件在plugin.xml中写的元素名和schema里定义的不一致导致解析器忽略了这个节点。排查这类问题时我通常按三步走第一步确认业务插件是否已经安装到运行实例里打开OSGi Console输入ss查看插件状态第二步检查扩展点ID拼写尤其是符号名前的插件前缀第三步在加载器代码里临时打印注册表拿到的所有元素名看能不能看到目标。只要三步都走一遍八成能定位问题。4.3 类加载冲突与重复库问题Eclipse Core内部统一使用POI做报表导出后业务插件很快就出现了NoClassDefFoundError。原因是一个旧插件把自己的poi.jar也放进了Bundle-ClassPath运行时每个插件都加载了自己的POI库Eclipse Core提供的服务返回的结果类型却来自另一个类加载器两边直接不匹配。这个问题在OSGi环境里非常典型。解决方法是把POI从所有业务插件的私有依赖中清除改成通过Eclipse Core统一提供并在导出包里显式声明Export-Package: org.apache.poi.ss.usermodel;version5.2.3, org.apache.poi.xssf.usermodel;version5.2.3业务插件通过Import-Package引用这些包。虽然改依赖的时候十几个插件都动了一下但之后报表相关模块完全不再出现类冲突。这也印证了一个原则公共第三方库放在核心层统一管理比每个业务插件各带一份要可靠得多。4.4 热部署失效与调试技巧开发Eclipse插件时代码热部署一直是让人又爱又恨的体验。有时候改了核心插件的逻辑保存后没生效界面上还是老行为。原因是Eclipse的运行时缓存里保存了旧的类定义扩展点这种静态配置更是被提前加载过动态刷新并不彻底。我的经验是改方法体时用Workbench自带的Hot Code Replace往往有效但改类的结构、加方法、改字段或者动了plugin.xml就必须重启应用。如果长时间调试时出现诡异状态直接停止运行配置然后再启动并加上启动参数-Dosgi.cleantrue这个参数会清掉OSGi运行时缓存强制重新解析所有插件。代价是启动时间会变长但保证了一个干净的环境。后来我们还配合Eclipse的“自动构建”功能和Tycho nightly构建每天凌晨生成一次最新插件包开发机直接从镜像库拉取比手工重建稳定很多。4.5 问题排查速查表整理一个开发过程中最有用的排查清单碰到问题可以直接对照现象可能原因解决方案服务引用为null插件启动顺序错误改用Declarative Services的Reference扩展点加载不到元素名/schema不一致比对plugin.xml和exsd中的名称ClassNotFoundError依赖包没有导出或导入检查Export-Package和Import-PackageNoClassDefFoundError同一个类被多个插件引入公共库统一由核心提供修改代码后不生效OSGi运行时缓存重启并加-Dosgi.cleantrue依赖无法解析p2仓库版本冲突固定目标平台版本内网保存镜像这张表后来直接放进了团队内部的Wiki新同学看一遍就能上手排查环境类问题效率提升非常明显。5. 如果再做一次Eclipse Core我会这样调整5.1 核心要薄扩展点要稳第一次设计时我一度想把所有“看起来公共”的东西全部放进Eclipse Core包括报表模板引擎、通用查询面板、权限判断工具。结果核心包越来越大版本升级时外围插件全部跟着遭殃。后来才想明白Eclipse Core不是一个收纳盒它应该像一个插座只提供最稳定的接口和最基础的运行机制具体业务引擎仍然放在业务插件里。核心真的做到足够薄后续扩展才好做。5.2 先定协议再写实现我们初期的最大教训是接口协议改得太频繁。今天觉得SessionContext里只需要用户名明天又要加部门权限后天还想塞IP地址。每次改动都触碰所有业务插件导致团队内部不断重复编译。后来调整了协作方式核心的重任在于先和业务插件开发者一起把扩展点的schema定下来再动手写实现代码。schema就好比一个契约契约稳定了核心代码怎么改都不易影响别人。最后分享一个小技巧每周做一次完整构建把所有插件的新版本和Eclipse Core一起编一遍任何依赖问题都会在第一时间暴露出来。早期我们总想着“下次一起构建”结果往往是在发布前三天连续加班。把构建动作固定成例行步骤之后才真正体会到“小步快跑”的好处。
