1.基本信息

　　摘要：

　　eclipse 提供了在eclipse ide外自动构建的能力。eclipse本身也是采用这种方式构建的。本文将分享eclipse自动构建的一些经验，详细介绍eclipse插件开发的自动编译过程。

　　环境要求：本文是基于eclipse 3.0环境进行描述的。如果你使用的是其他版本的eclipse，在试验时你可能需要对一脚本进行修改。

　　2.ant介绍

　　ant是一个平台无关的java项目构建工具。使用ant可以方便的将您开发的项目的构建流程有效的管理起来，可以方便的提供给用户可发布的软件产品。使用ant来做项目构建工具的优点被越来越多的人认可，目前开源的java项目几乎都使用ant做构建工具。现在还出现了dot net平台上的ant构建工具。ant已经成为了java项目构建的事实上的标准。

　　ant通过执行构建脚本来生成可发布的软件包。构建脚本为xml格式。每一个ant脚本中包含一个project, project下又包含许多的target, target由一个或多个ant task组成。ant的task允许用户自己进行扩展，当ant提供的task不能满足你的需要时可以自己开发一个task。一个ant脚本可以调用另外一个ant脚本，所以可以设计出精巧的脚本回调结构， 使您开发的ant脚本更易于维护和扩展。

　　eclipse将ant集成到了它的ide中，开发完一个插件项目，你可以方便的生成插件项目的构建脚本。但是eclipse的插件项目一般比较依赖eclipse的开发环境，如果直接使用ant来执行eclipse生成的构建脚本则需要做许多额外的环境设置的工作。eclipse的开发者考虑到了这一点，在eclipse中提供了一个ant的eclipse application。你可以使用命令行的方式执行它，像下边这样：

　　3 eclipse插件自动构件过程

　　3.1准备工作

　　1.全面分析你需要构建的项目

　　在编写ant脚本前，需要对将要构建的项目有一个全面的考虑。 列出你的项目有多少个子项目需要进行构建。各个子项目之间的依赖关系如何，这关系到在脚本中对各个子项目的构建先后顺序的安排。其次，列出项目的中间提交物清单。也就是构建的结果是什么。对于一个小项目构建的结果也许就是一个jar文件，但是对于一个几十人的开发团队开发的项目，构建结果可能包含有服务端的构建结果，客户端的构建结果，还有web程序。中间提交物清单应该包括构建结果的文件名和存放路径以及将来部署时在未来系统中所处的逻辑位置。

　　2.列出构建的工作流程

　　也就是说在你的构建过程中先做什么，后做什么。例如通常的构建过程是：从cvs服务器获取最新版本的代码，然后对代码进行编译，之后打包部署。这个过程如果一下子想不清楚，可以先列出最顶层的过程，然后不断细化。

　　3.了解构建的依赖环境

　　一般项目都是在ide中开发，项目的配置信息都通过ide的设置界面进行设置。这些设置项比较分散。如果要在使用ant成功构建项目，则需要对ide中的设置导出，否则构建通常会失败。另外需要了解项目使用了那些第三方的开发包，在编写构建脚本时需要考虑。eclipse的插件项目可以方便的导出ant构建脚本，供其他顶层脚本调用。

　　3.2自动构建脚本编写

　　在对你要构建的项目有了一个通盘的考虑之后，可以开始编写构建脚本了。最直接的方法当然是自己从头开始编写构建脚本。或者是使用一个顶层脚本按照子项目的依赖关系依次调用各个插件生成的构建脚本build.xml文件。这样能为我们节省很大一部分时间。但是实践证明，即使是这种方式工作量还是很大。例如我们目前的项目的插件数目已经有几十个，依次调用一遍各个插件的build.xml文件依然是一件很累和乏味的事情。实际上我们也是这样做的。有没有更方便的方法呢？

　　原来，eclipse本身提供了一个插件构建的脚本框架，我们只需要像填空一样编写很少的脚本代码就可以完成整个复杂的构建过程。
　　3.3eclipse自动构建框架介绍

　　下面我们用一个例子来说明整个的构建过程。我们在下面的例子中将会编写sdk.examples的构建脚本。sdk.examples是eclipse的示例代码，你可以在eclipse的cvs里得到。

　　在开始之前你需要下载cvs.exe和unzip.exe,并将他们拷贝到系统目录中，或者放置在环境变量%path%可以找到的地方。cvs.exe和unzip.exe可以从以下地方下载：

cvs client version 1.10 or higher on system path.
info-zip zip and unzip executables on system path.

　　第一步先获得org.eclipse.releng.eclipsebuilder。org.eclipse.releng.eclipsebuilder是eclipse的发布引擎。

d:\build＞cvs -d :pserver:anonymous@dev.eclipse.org:/home/eclipse export -r r3_0_2 org.eclipse.releng.eclipsebuilder

　　org.eclipse.releng.eclipsebuilder中的readme.html描述了如何构建一个eclipse的组件。

　　在默认的情况下，为了获取3.0.0版本的sdk.examples，我们需要修改org.eclipse.releng.eclipsebuilder/sdk.examples/build.properties文件。

mapversiontag=r3_0_0

　　现在我们可以在控制台的命令行中开始构建过程。

d:\build\org.eclipse.releng.eclipsebuilder＞set eclipse_home=d:\eclipse\eclipse-3.0.0
d:\build\org.eclipse.releng.eclipsebuilder＞java -cp %eclipse_home%\startup.jar org.eclipse.core.launcher.main
-application org.eclipse.ant.core.antrunner -buildfile build.xml
-dcomponent=sdk.examples -dconfigs="*,*,*" -dbaseos=win32 -dbasews=win32 -dbasearch=x86 -djavacfailonerror=true
-dpde.build.scripts=%eclipse_home%/plugins/org.eclipse.pde.build_3.0.0/scripts -dbaselocation=%eclipse_home%

　　命令行中的compoent属性是你将要构建的组件名称。也就是你在d:\build\org.eclipse.releng.eclipsebuilder目录下的一个子目录的名称。在这个子目录下有build.properties和customtargets.xml文件。

　　build脚本将会使用d:\build\org.eclipse.releng.eclipsebuilder\src目录作为默认的build目录。你也可以将-dbuilddirectory=${basedir}/newdirectory加入到命令行中指定你自己的build目录。

　　构建完成之后，装配完成的可分发的软件包和构建日志位于build目录下的一个子目录，这个子目录的名字由buildlabel属性定义。默认的这个目录的名称由”i－”开始，并包含构建时刻的时间戳。

　　命令行中的baselocation属性用户指定eclipse启动的目录。同时，构建过程中如果在build目录中找不到一个plugin,会到baselocation目录去查找。因此，在你自己的构建过程中的第三方的插件也应该位于%baselocation%/plugins目录下，才能保证构建过程成功。baselocation目录下不能包含任何你将要构建的插件，如果baselocation目录下包含了sdk.examples，构建过程将会出错。

　　3.4构建过程分析

　　在下面的部分我们将为你分析构建过程中的一些细节。首先我们先熟悉一下和构建有关的几个重要文件和他们的位置：

build.xml

　　位于 org.eclipse.pde.build_＜version＞/scripts 目录下。该文件提供了一个从prebuild到postbuild的过程的一个骨架。

generictargets.xml
　
　　位于org.eclipse.pde.build_＜version＞/scripts目录下。包含了像fetchelement, generatescript, processelement, assembleelement等ant task。

customtargets.xml

　　位于org.eclipse.releng.eclipsebuilder目录的子目录下。如sdk.examples.customtargets.xml文件将会被org.eclipse.releng.eclipsebuilder目录下的build.xml文件调用。在customtargets.xml文件中将会调用generictargets.xml文件中的target。customtargets.xml文件的主要职责是定义将要构建的features和从那里得到构建过程中需要的map文件。关于map文件将会在后边介绍。

　　4. build.properties

　　位于org.eclipse.releng.eclipsebuilder目录的子目录下。build.properties属性文件中定义了一些构建过程中build脚本使用的一些属性。

　　下面我们来看一下整个构建过程的序列图如下：


　　上面的序列图给出了整个构建过程的一个概览。

　　1.d:\build\org.eclipse.releng.eclipsebuilder目录下的build.xml首先会设置一些与构建过程有关的环境设置变量，然后调用$eclipse_home\plugins\org.eclipse.pde.build_3.0.0\scripts下的build.xml文件。

　　2.$eclipse_home\plugins\org.eclipse.pde.build_3.0.0\scripts下的build.xml文件会一次调用自身的prebuild,fetch,generate,process,assemble,postbuild的几个target。在这几个target中又会一次调用customtargets.xml文件。所以说build.xml是整个构建过程的骨架，它定义了构建过程中的“构建准备”，“fetch构建所需资源”，“生成插件构建所需build.xml文件”，“编译”，“组装”，“构建完成后的相关工作”等阶段。

　　3.prebuild过程中要做的一件重要事情就是回调customtargets.xml文件的getmapfiles target获取map文件。map文件定义了将要构建的所有插件在cvs中的位置。map文件的格式如下：
feature|fragment|plugin@elementid=＜cvs tag＞,＜access method＞:＜cvsuser＞@＜cvs repository＞,＜cvs password＞[,＜repository path＞ (no starting slash) ]
map文件从cvs获得后会放在builddirectory目录下的map子目录下。map文件可以是有多个的，脚本会将map目录下的所有map文件连接为${builddirectory}/directory.txt文件。

　　4.fetch过程同样会调用customtargets.xml文件中的allelements target。allelements target又将调用$eclipse_home\plugins\org.eclipse.pde.build_3.0.0\scripts下的generictargets.xml文件的fetchelement target。fetchelement target中会调用eclipse内置的ant task “eclipse.fetch”。“eclipse.fetch”会自动生成一个fetch_${plugin_id}.xml文件。它生成的原理是分析feature.xml文件，获取一个feature内包含的所有插件id, 然后在map文件中查找插件在cvs中的位置并生成fetch_$(plugin_id).xml文件。然后会执行该fetch文件将插件代码获取到本地构建机器上。

　　5.generate过程同样会回调customtargets.xml文件的allelements target。allelements target又将调用$eclipse_home\plugins\org.eclipse.pde.build_3.0.0\scripts下的generictargets.xml文件的generatescript target。generatescript target中会调用eclipse内置的ant task “eclipse.buildscript”。“eclipse.buildscript”的作用是根据插件下的plugin.xml文件生成构建插件所需的build.xml文件。大家注意到在脚本中将这个过程自动化了。同样的我们可以在ide环境中的插件开发透视图中选中一个plugin.xml文件，执行右键菜单中的pde tools-＞create ant build file命令生成build.xml文件。如下图所示：


　　但是，在开发过程中经常会添加对新的插件的引用而没有重新生成build.xml文件，这是导致构建过程失败的主要原因。另外一个缺点是如果使用在ide环境中生成的build.xml文件，构建环境必须和ide环境设置一样。开发环境和构建环境设置不一样也是导致构建过程失败的最常见的原因。

　　在构建时刻生成build.xml文件可以避免以上两个缺点。

　　6.process过程同样也会回调customtargets.xml文件的allelements target。allelements target又将调用$eclipse_home\plugins\org.eclipse.pde.build_3.0.0\scripts下的generictargets.xml文件的processelement target。 processelement target调用自动生成的插件build.xml文件，完成对插件的构建。

　　7.assemble过程将完成插件的组装过程。

　　8.postbuild过程回调customtargets.xml的postbuild target。

　　3.5构建你自己的插件

　　前面我们构建了sdk.examples，并且分析了整个自动构建的全过程。采用上面介绍的构建方法有一个限制就是你必须有一个feature项目。如果没有就先建立一个。菜单路径是file-＞new-＞project...-＞plug-in development-＞feature project。在打开的向导中输入feature项目的名称，然后选择你要构建的插件并且包含到feature项目中。如果你不想将你要发布的plugin部署为一个feature，你只需要修改feature项目中的build.properties文件，删除掉bin.includes属性就可以了。

　　构建你自己的插件，你需要准备四个文件：

　　1．a map file for fetching the sources ，map文件一般情况下是存放在cvs中，在构建开始时从cvs下载。

　　2．customtargets.xml ，customtargets.xml文件位于位于d:\build\org.eclipse.releng.eclipsebuilder目录的子目录下。如sdk.examples。org.eclipse.releng.eclipsebuilder是eclipse的release engine。可以从eclipse的cvs中获得。

　　3．build.properties ，build.properties文家定义了构建过程中使用的环境变量。你可以根据自己的情况修改。

　　4．a shell script, which starts an eclipse instance as antrunner。运行eclipse实例的脚本。在本文的前面已经有过介绍。

　　下面是一个map文件片断的示例，你可以根据你自己的情况修改用户名，密码，package名称，和cvs分支名称。

feature@org.rubypeople.rdt=head,:ext:cvs.sf.net:/cvsroot/rubyeclipse,,org.rubypeople.rdt-feature plugin@org.kxml2=head,:ext:cvs.sf.net:/cvsroot/rubyeclipse, plugin@org.rubypeople.rdt=head,:ext:cvs.sf.net:/cvsroot/rubyeclipse, plugin@org.rubypeople.rdt.core=head,:ext:cvs.sf.net:/cvsroot/rubyeclipse,

　　custometargets.xml提供了构建过程中回调的钩子。custemertargets.xml文件的模板在org.eclipse.pde.build插件的script目录下可以找到。下面是customertargets.xml文件的一个片断。allelements target中定义了你要构建的feature id。这里的feature id不是feature manifest文件中定义的feature，而是用于在map文件中查找cvs信息时使用的id。getmapfiles target会将map文件下载到本地的${builddirectory}目录下。assemble target会调用生成的assemble脚本文件对编译结果进行组装。

＜target name="allelements"＞ ＜ant antfile="${generictargets}" target="${target}" ＞ ＜property name="type" value="feature" /＞ ＜property name="id" value="org.rubypeople.rdt" /＞ ＜/ant＞ ＜/target＞ ＜target name="getmapfiles"＞ ＜property name="cvsroot" value=":ext:cvs.sf.net:/cvsroot/rubyeclipse" /＞ ＜cvs cvsroot="${cvsroot}" dest="${builddirectory}/maps" command="export -r ${mapversiontag} org.rubypeople.rdt.build/map"/＞ ＜/target＞ ＜target name="assemble.org.rubypeople.rdt"＞ ＜ant antfile="${assemblescriptname}" dir="${builddirectory}"＞ ＜property name="zipargs" value="" /＞ ＜/ant＞ ＜/target＞

　　结论

　　回顾一下整个构建过程，在customtargets.xml文件中我们定义了每一构建过程中供$eclipse_home\plugins\org.eclipse.pde.build_3.0.0\scripts下的build.xml文件回调的target。对于一些复杂的通用功能如生成获取cvs中插件代码的fetch.xml文件、生成build.xml文件等由generictargets.xml来完成。这样一种结构最大限度的保证了customtargets.xml文件的简洁性、可维护性、可扩充性。eclipse提供了这样一个优雅的构建脚本框架，用户只需要编写自己的customtargets.xml文件。customtargets.xml文件的模板可以在$eclipse_home\plugins\org.eclipse.pde.build_3.0.0\scripts找到。我们只需要拷贝一个，然后稍加修改就可以完成该项工作。

　　customtargets.xml文件中预定义了很多和构建过程对应的target。这些target都会被$eclipse_home\plugins\org.eclipse.pde.build_3.0.0\scripts调用。一个例子可以很好的说明这种回调的方便性。当我们构建一个包含有help文件的插件时，一个预先要做的工作就是先要将help文件打包成zip文件。我们可以修改customtargets.xml中的preprocess target：