转载：基于Ant的集成开发方式

开发阶段，不同用户环境下对程序的发布、部署要求可能不同，比如：配置参数的设置，系统的安装路径，第三方库的路径（假如不打算将第三方库加入发布的ZIP包内的话）。我们可以在编写build文件时借助定制properties来解决这个问题，即将一些配置项抽象为properties，也可以将这些properties单独放在一个外部文件里。在多人协作开发时，如果将这些易变的properties也加入CVS的话，则每此不同人员从CVS下载程序到本地时就必须再次更改，而这种更改可能要伴随CVS中相应文件的更新（build文件，或者是独立的properties文件），这显然是不合适的。

为此，我们可以利用每台本地机上的user.home路径，将properties文件放到那里。该文件不用放到CVS中，build时让Ant自动去目录下找该文件并加载。至于user.home路径，linux下为/home/，windows下一般为C:Document and Settings。其中为当前用户名。也可以在Ant中利用系统环境变量结合进行设置，这样更为灵活。windwos下的环境变量为HOMEPATH，linux下为HOME。

前面提到的properties文件单纯用于build过程，对于最终发布系统中所带的properties文件，我们也可以做类似的灵活性改进。首先编写一个properties的tmplate文件放入CVS中，在build文件的init target中先将tmplate文件copy成“实例”文件，然后将某些可配置项做字符串替换。我们可以将这些可配置项的替换值放到另一个properties文件中，而该文件则不放入CVS，也同样的放到user.home路径下。字符串替换可以用或者。

当然，在发布完整的安装包时，可能也需要将这些散落在本地机的properties文件“加入”到安装包中。一种办法是，编写一个示范性的template文件，加入到CVS中，开发阶段并不使用该文件。在生成安装包时将该template文件也打入包中，同时，要在随产品发布的安装文档中加入相关说明。这样，用户就可以按照说明，手工copy一个“实例”文件，然后做一些针对性的配置。这种方法的不足在于要求用户做额外的工作，如果安装包自包含特性很好的话，那么用户也许只需要简单的运行一下run.bat（对于可运行版本而言），或者build.bat（即使是可运行版本也可能存在build过程，就像AnthillPro）。为此，我们需要在完成发布任务的Target中生成一个“final release”的properties文件，这样的文件只用于最终发布是打入包中。

改动频繁的properties应该独立于build.xml，单独作为外部properties文件。尤其是用户相关的properties，也就是所谓的user-specific properties。这样的文件不用放到SCM中，而是放到各自本地机的user.home中。

长期不变的properties通常可以放到build.xml文件内的首部。这些properties也有存在的必要，开发阶段的偶尔调整是有可能的，它们的作用就像程序设计中的常量定义——改动一处，全盘皆变——方便而又易于维护。当然，这些properties应该是随build.xml文件一起保存在SCM中的。

更复杂的手段是：

除user-specific配置项外，针对项目的一些全局性配置提供project-specific的properties文件。这些配置项的易变性往往低于user-specific配置项，但是长期的开发周期中依然有可能变动，此类properties文件应该放入SCM中。一个最明显的例子就是project.version，该配置项的用途之一是生成可发布软件时作为路径或文件名的一部分，就像tomcat的home路径通常是jakarta-tomcat-。

user-specific配置项和project-specific配置项允许互有交叉。当两者冲突时，user-specific可以覆盖project-specific，即前者的优先级更高。根据“immutable properties”原则，这就意味着，build.xml文件中应该首先加载user-specific properties。

根据实际情况，可能还有一类最易变的配置项。那就是每次build过程中都可能变化的properties，称之为build-specific properties。此时，我们可以利用Ant的命令行参数-D来进行配置。由Ant的特性我们可知，此类配置项的优先级是最高的。当然，一般情况下这种配置项还是少一些为好。

加上前面提到的位于build.xml文件内的properties，我将其暂命名为inner properties，各类proeprties的易变性和优先级情况如下：

类别	易变性	优先级	是否位于SCM中
build-specific properties	高	高	No
user-specific properties	中	中	No
project-specific properties	低	低	Yes
inner properties	低	低	Yes

综上，四种不同级别的properties，足够我们应付大多数项目构建了。