用Velocity进行配置文件信息的集中管理
Apache从他诞生的那天起就改变着我们的生活方式。而Velocity的出现也不是个例外。Velocity是一个基于java的模板引擎（template engine）。它允许任何人仅仅简单的使用模板语言（template language）来引用由java代码定义的对象。 当Velocity应用于web开发时，界面设计人员可以和java程序开发人员同步开发一个遵循MVC架构的web站点，也就是说，页面设计人员可以只关注页面的显示效果，而由java程序开发人员关注业务逻辑编码。Velocity将java代码从web页面中分离出来，这样为web站点的长期维护提供了便利，同时也为我们在JSP之外又提供了一种可选的方案。
曾几何时，还记得自己每次对JSP页面做一点小小的改动，就需要痛苦的几秒钟等待时间，好让JSP容器按部就班的把JSP页面先生成为Java文件，然后又将该Java文件编译成class文件，最后再将结果返回。然后又可能由于是自己的一时疏忽导致的一个小bug，使得你不得不再次去重复同样的工作。现在，当我们有了 Velocity 之后，页面的修改不再变成一件让人痛苦的事情。它可以让你彻底体验页面改动带来的飞速回报。这也是 Velocity 值得称道的地方之一：他拯救了我们的WEB程序员们。于是，你Google一下，随便就可以在网上找到成千上万的关于 Velocity 如何进行Web开发的相关文章。
Velocity之所以如此famous、如此优秀，是因为Velocity的能力远不止web表现层开发这个领域，Velocity的诞生也为开发界带出了另一个话题——模板化（至少是使得模板化更加简单易行），而web表现层的应用仅仅只是“模板化”话题中的一个分支而已，我今天想聊一聊关于 Velocity 为大多数程序员所不够关注但是又非常重要的应用——配置文件模板化。
今天的软件开发界是一个开源插件满天飞的世界。什么Hibernate.cfg.xml、Hibernate.hbm.xml、struts-config.xml、spring.xml、web.xml甚至是tomcat、JBoss的一些配置都需要我们在发布产品的时候一并进行配置。其实，一个通常的工程其配置文件远远不止这些，在工程应用中，我们为了提高系统的灵活性，在开发阶段会引入大量的配置文件，而这些配置文件都会由于客户需求的变化、工程运行环境的不同出现不同的差异。同时又与操作系统（windows、Linux）、数据库、网络环境的参数有密切的关系。常态下，需要正确配置这些信息必须首先是一个对系统非常熟悉的Senior Engneer。但是，事实上是我们不可能为了解决这些系统配置的信息去每次找几个Senior Engneer去处理这些得不偿失的事情。那么问题就来了，既然不是由Senior Engneer来处理这些事情，那么那些其他的Junior Engneer有没有足够的能力去处理这些事情。有什么办法可以在这两者之间做出权衡呢。
一种可行的解决方案就是将这些配置成可替换的参数，然后找一个文件对这些需要配置的数据进行集中管理，这样当我们需要修改某些配置信息时，我们只需要在该文件中集中处理然后执行一个简单的替换操作所有的事情就全部OK了。于是我们想到了Velocity，这个看起来处理模板数据本该是天性使然的家伙，能否给我们一个预料之中的惊喜呢。其实我们的问题就转移到了，Velocity是否有能力将我们的参数一一进行提换的问题了。
小实验马上展开：
根据提供的接口我们很快写出了上面的这段代码，其中createFile() 方法是参数替换的具体实施者。
其中用到的两个配置文件内容分别如下：
但是如果你真的对Velocity的编码设置感兴趣org.apache.velocity.runtime.resource包下的Resource类可能会对你有一定的参考价值。
运行程序后得到的generator.properties.txt内容如下：
第三方第三方第三个大股东范甘迪说个======伏羲狂徒======改动热管热个人股热管热管大商股份第三个
passport=welcome to danlley's home page
messages=hello velocity
这样，一个简单的模板管理的雏形就已经呈现在我们的面前了。其中first_step.properties在这里可以作为一个集中管理者，而generator.properties则是代替换的参数模板文件，最后generator.properties.txt则是我们需要的“熊掌、鱼翅”。思路已经有了，实现的可行性也已经验证了。那要想把他真正用在工程中，剩下的就只是对其进行扩充了。
看似好像没什么问题了，但是好像又不是很完美。为什么！用起来不方便，如果是在Ant和Maven中，我可以把整个参数替换过程放置在某个测试类中，然后运行一下，但是保证这个测试类的运行要先于其他测试类的运行就是一个令人头疼的事情，而且，参数替换过程本来就不属于工程代码的一部分，他应该是一个独立的组件才对。所以我们就把它开发成一个组件。不要拖动滚动条，因为下面没了，呵呵呵呵。我打算在下一个专题中来专门阐述一下基于Velocity的Ant和Maven插件开发过程。关注我的博客吧，^_^
?
参考资料：
http://ahuaxuan.iteye.com/blog/71430
http://www.open-open.com/open2821.htm
