EclipseWork：学习与改进

9月份换了一个公司，目前的主要工作是为公司的新开发框架作一个配套的开发环境。在我的设计里面，开发环境应该包括MAVEN、SVN、DB、ECLIPSE IDE、TD、JIRA等等。目前我还在整IDE这一部分，这里做一个小结。

作为框架配套的开发环境，最重要的功能应该是自动代码生成了。如果公司完全采用原版的流行框架，比如Struts2+Spring+Hibernate+JQuery，网络上代码生成的工具应该很多。但我相信没有一家有实力的公司会简单的把开源框架往那边一堆，说这个就是我们的开发框架了。从任何意义上来说，按照公司自己的业务特性对开源框架做一些扩展和裁剪是非常必要的。因此拥有一套和自己的开发框架匹配的好用的IDE，是每个公司梦寐以求的事情，它不仅能减少无数重复的编码劳动，还能让每个程序员提交的代码更可靠、结构更标准，让程序员将更多的时间专注于业务功能的开发。

 

感谢Eclipse的平台化插件式设计，让这样的开发和设计工作变得相对容易完成。

 

我这人一向不喜欢从0开始研究一个新领域，寻找一个合适的现成的IDE成了我的第一目标。感谢Baidu，感谢Google，感谢CSDN，感谢JavaEye，感谢无数乐意分享自己心得体会的人，感谢无数开源爱好者，经过不懈的Search，最终我锁定了由 ricardolecheta 贡献的EclipseWork 插件。

 

EclipseWork插件的目标是为Struts2的前身，WebWork框架生成源代码及配置文件。网络上关于EclipseWork的介绍也不少，比较详细的可查看 eclipsework 学习笔记 - shishi11的专栏 - CSDN博客

 

闲话少说，安装完EclipseWork及其依赖的插件EasySQL之后，我将其示例向导运行了一下，发现效果还是不错的。这个插件的优点在于其设计理念：让不会SWT/JFace的开发人员能够自定义代码生成向导。主要体现在几个方面：

 

1. 全XML配置方式的向导定义方式，通过简单修改向导定义文件，就可以创造出不同的向导，并拥有期待的行为和结果。换句话说，只要遵守了EclipseWork的一些基本要求，向导的行为是脱离插件本身的。

2. Velocity语言格式的模板文件，继承了velocity语言的优势。

3. 允许对向导进行分类，向导的管理比较方便。插件还提供了一个模板视图，以树形方式展现了当前定义的向导。

4. 提供了对各种资源的访问方式，比如对JDT的IJavaElement模型进行了适配器方式封装、数据库的访问、数据库表结构的模型、文件及文件夹等。理论上可以满足各种资源请求。

5. 对向导中常用的控件进行了封装，典型的有Component系列、VariableTable等，并提供了一个定义常量的Preference页面。

6. 输出方面，几乎可以对所有类型的文本文件进行创建，并支持对XML文件进行更新。

 

 

可是这个插件的不足之处也是非常的明显，比如 EclipseWork和EasySQL从2007年开始已经停止更新了。另外 这两个插件还是有很多问题：

 

1. 没有文档。对于一个软件产品来说，没有文档，没有使用手册，除非这个产品很容易上手，否则后果很严重。

2. 描述不准确，没有国际化。比如EclipseWork中将向导称为模板，常常让我在使用的时候感到不适应

3. 使用不方便。为了调用EclipseWork中的模板，必须首先打开向导管理视图，然后在向导管理视图里面双击您需要打开的向导。在实际的开发过程中，屏幕资源是非常宝贵的。而一个树形的向导视图要占去不小的屏幕资源。

4. 向导的使用没有限制，或者说没有上下文。在没有合适的上下文中调用一个向导，可能会产生意想不到的问题

5. 部分功能明显还处于修改未完成的阶段。代码中有很多FIXME的注释；有一些已经设计了，却还没有实现的功能，比如IEWWizardPage接口的enterPage方法从没有被调用；有Table控件的页面，布局都很失败；向导管理视图好像要实现一个自定义向导的功能，后来又没有实现；

6. 代码结构混乱，不符合程序设计的准则。由于访问数据库资源依赖于EasySQL插件，EclipseWork中形成了对EasySQL插件的紧耦合。而循环依赖、紧耦合等现象在两个插件中都普遍存在。我在阅读这两个插件的代码时常常被其中混乱的分层搞晕。不过richard一个人，写了EasySQL、EclipseWork及abstractPlugin.jar三个东东，也不容易～

7. abstractPlugin里面的一些方法挺好，但有时候又把简单的问题给复杂化了。

8. 最严重的问题，就是向导管理配置文件和向导定义配置文件都没有schema。这样对于一个向导的定义者来说，根本不知道自己的向导应该要怎么写，而且非常容易写错，让这个插件的实用性大打折扣。

 

发现了以上问题后，我着手对这两个插件进行了改造。到目前为止， 除了仍沿用两个插件的设计理念之外， 已经将两个插件改得面目全非。改造如下：

 

1. 对所有的资源模型进行抽象和重构，大量使用接口和范型，并因此删除了很多不需要的实现类。抽象出来的共同的接口、抽象类作为第三方LIB分别引入两个插件。

2. 对两个插件的依赖关系进行解藕。目前只有两个插件的Plugin类有依赖关系。还在研究将插件捆绑到平台中的指定变量的方式，这样两个插件就可以完全解藕了。

3. 对两个插件进行了国际化

4. 为EclipseWork插件添加了右键菜单，并仿造plugin.xml的实现方式，在向导管理文件中定义了菜单过滤器。当用户在NavgationExplorer上右键点击一个资源，将会动态显示和此资源匹配的向导。向导的调用更方便，不需要显示向导管理视图。

5. 修改了所有FIXME标记，重写了WizardPage.setVisible(boolean visible)方法调用enterPage；对所有包含Table的页面进行了重写。去掉了自定义模板功能，及很多其他不需要的功能。

6. 添加了一个typemodel-page页，这个完全是公司的需要。其中实现了动态Table，应该是Component中table标签想达到却没有达到的目标。

7. 对variable-page进行了重定义，简化只剩下三个固定的列：name, value, description，并且只有value列可以修改，去掉添加和删除按钮。

8. 重新实现了IJavaElement相关的Utils，添加了一些条件，比如名称过滤、范围过滤、类型过滤，都可以在配置文件中通过XML属性进行选择

9. 抽象和重构两个项目，大量的Utils方法，更好的分层，更清晰的依赖关系。不过说实在的，我仍然不能肯定现在里面没有实现类的循环依赖了。

10. 重写了preference中的自定义常量配置页面，修改插件上下文存取自定义常量的方式。

11. 在输出方面，增加了对projectnature的支持。后续还要支持更多的输出。

12. 严格定义了两种配置文件的schema，修改了很多节点的名称、属性、属性限制，并对JDom×××Parser进行了大量的修改。这个过程极其痛苦，我决不愿意再来一次。

13. 支持数据库表模型的注释。这个是意外发现的，Oracle的DatabaseMetaData不支持注释，只能自己用查询语句查出来。

14. 用pageContext在wizard的页面之间传递上下文，将页面彻底解藕。

15. 让代码模板支持文件嵌套语法。

 

由于是公司的项目，不能开源，分享一下心得体会。

1. 插件开发不复杂，而且很有技术含量，比做JEE有乐趣一些

2. 学习，学习，再学习

3. 多使用搜索引擎，要相信你不是第一个遇到这个问题的，也很可能不是第一个会解决这个问题的

4. 努力做的更好，让后来者学习你，而不是鄙视你

5. 尽可能把结构设计得简单而优美

6. 在时间压力下，偶尔对bad smell的屈服是必要的