这里先说异步调用链，MVP的如何实现页面区块的嵌套放在下一次。

客户端通常需要调用多个远程接口来装载页面需要的数据。如果某写接口调用失败，则相应的数据显示不了，并且一些RPC之间对数据有依赖性。例如一个用户登录后，转到应用的首页，首页需要显示当前登录的用户信息和他的朋友列表。那么在 onModuleLoad 的过程中需要执行两个调用。分别是 accountService.getCurrentUser() 和 friendService.listFriends()。这个时候如何第一个调用失败那么程序就不应该执行第二个调用，而是直接报告数据读取出错，否则页面上某些数据显示不出来，比较奇怪。这个时候就需要异步调用链。为此我写了一个接口和一个类来实现链式调用。

AsyncCall.java —————————-

/**
* 异步调用接口，实现这个接口的对象可以添加到 AsyncCallChain 中，支持逐个调用。
* @author zzc
*
*/
public interface AsyncCall {
void call(AsyncCallChain chain) throws Exception;
}

——————————————–//

AsyncCallChain.java ————————-

import java.util.ArrayList;

/**
* 异步调用链
* @author zzc
*
*/
public class AsyncCallChain {
public static enum Status {READY, AFOOT, END}; // 准备好，进行中，结束了
private ArrayList<AsyncCall> calls = new ArrayList<AsyncCall>();
private int index = 0;
private Status status = Status.READY;

public void go() throws Exception {
status = Status.AFOOT;
doNext();
}

public void doNext() throws Exception {
if(calls.size() > index) {
index++;
calls.get(index-1).call(this);
} else {
status = Status.END;
}
}

public void addCall(AsyncCall call) {
calls.add(call);
}

public Status getStatus(){
return status;
}
}

———————————— //

怎么使用上面的接口和类？

首先我们先编写两个类 GetCurrentUserAsyncCall 和 ListFriendsAsyncCall，都实现 AsyncCall 接口。这里给出 GetCurrentUserAsyncCall 的部分代码。

public class GetCurrentUserAsyncCall implements AsyncCall {
@Override
public void call(final AsyncCallChain chain) throws Exception {
service.getCurrentUser(new AsyncCallback<User>(){
@Override
public void onFailure(Throwable caught) {
// 调用失败，应该显示数据读取错误，并且终止进一步的操作
...
}

@Override
public void onSuccess(User user) {
// 调用成功，执行下一步
chain.doNext();
}});
}

}

然后在 onLoadModule 的过程中创建链，并逐个执行。

AsyncCallChain chain = new AsyncCallChain(); // 创建链式调用
chain.addCall(new GetCurrentUserAsyncCall(clientFactory)); // 获取当前用户信息
chain.addCall(new ListFriendsAsyncCall(clientFactory)); // 获取朋友列表
chain.addCall(new HistoryHandleAsyncCall(clientFactory)); // 历史处理（MVP用来激活指定的 Activity）
chain.go(); // 开始执行

Eclipse提供一套常用的UI模型，支持多种操作系统。按照Eclipse提供的可移植API编写的插件，不需要做任何修改，就可以在所有支持的操作系统上运行。

Eclipse 的核心，一个能够动态发现，装载，和运行插件的架构。平台负责发现和运行代码。UI提供一个标准的引导用户使用平台的模型。插件则专注于小数量的任务上。是哪种类型的任务呢？定义，测试，动画，发布，编译，调试，绘图…一切只要你想得到。

开放的架构

Eclipse 提供一个开放的架构，其他的开发团队可以在他们专长的领域里面给这个平台开发插件。如，仓库专家建造后端，使用方面(UE)的专家建造前端。可以增加重要的新功能部件和层次，而不会与其他的工具冲突。

从用户的角度来看，Eclipse 平台使用一个共同的工作台的模型。你可以将开发的工具通过它预先定义的钩子（extension points）插入到工作台中。

这个平台是由插件以层次的方式建成，每一个插件定义了更低层次的插件的扩展点的扩展，也可为更高层次的插件自定义扩展点。这种扩展模式可以让开发者给基础工具平台增加不同的功能。每一个工具生产出来的人工品，比如文件和其他的数据，由一个共同的平台资源模型来协调。

插件的开发者可以从这个架构中获得很多。这个平台管理多种不同的运行时环境，例如不同的操作系统或者工作组服务器环境。插件开发者能够专心完成他们的任务，不用担心有关集成的问题。

平台架构

Eclipse平台本身就是一个子系统，在由一个或者多个插件中实现。这个子系统在一个小型的运行时引擎的上面建造。下图做一个简单的描绘。

拼凑成这个子系统的插件为给平台增加行为， 而定义了多个扩展点。下表描述这个平台的主要运行时组件，由一个或者多个插件实现。
平台运行时    定义了扩展点与插件模型。动态发现插件和在一个平台注册表中维护插件及其扩展点的信息。当需要响应用户对平台的操作时，插件被启动。运行时使用OSGi框架实现。
资源管理（workspace）    为资源的创建和管理，定义的API。这些资源包括项目、文件和目录，都是由工具生成并且保存在文件系统里。
工作台UI    实现用户纵览平台的座舱。定义了扩展点，为增加UI组件，比如 views 或者 菜单 actions。提供附加的工具（JFace和SWT）来建造用户界面。UI服务是结构化的，因此UI插件的子集能够被用于建造RCA，独立与资源管理和workspace模型。以IDE为中心的插件为纵览和操纵资源，定义了另外的功能。
帮助系统    像书籍一般，给插件来定义扩展点，能够提供帮助或者其他的文档。
团队支持    为管理和版本化资源，定义了一个团队编程模型。
调试支持    定义了一个语言独立的调试模型和UI类，为的是建造调试器和运行器。
其他工具    其他的插件，比如支持搜索和资源比较，使用XML配置文件执行建造，从服务器那里动态升级平台。

盒子之外

离开了Web，基础平台就是一个IDE，没有什么特别的。

它是一个检查平台的最终功能的插件。这就是为什么Eclipse SDK和额外的插件一起装运，来增加SDK的功能。

你的插件可以提供这样的支持，编辑和操作额外的资源类型，例如Java文件、C程序、Word文档、HTML页面和JSP文件。

挑战

我们要求达到一个这样的集成水准，魔法般将独立的开发工具揉合到一个设计套件中。已有的工具可以足够简单的迁移到平台中，不需要强塞硬撬。

平台应该是开放的，用户可以选择工具，并且他们知道供应商在底层平台的开发过程中说了些什么。

它应该足够简单，容易理解，足够强壮，无须额外的粘和剂就支持集成。

提供工具，将平凡常用普通的任务自动化。足够稳定，让业界强壮的工具在其上面建造。非常有用，平台的开发者可以使用它来建造它本身。

上面都是Eclipse的目标。这个手册将帮助你检查Eclipse如何去实现这些想法。

+ 建造的生命周期基础

Maven 2.0 的中心概念就是建造的生命周期。项目成品的建造和分发的过程被明确定义。

对于建造一个项目的个人来讲，需要做的事情就是学习一些建造Maven项目的简单命令，以及POM，确保得到想要的结果。

有三个内建的建造生命周期：default, clean 和 site。defalut 生命周期处理你的项目的部署，clean 生命周期处理项目的清理，site生命周期处理你的项目站点文档的创建。

++ 一个建造的生命周期是由过程组成

每一个建造生命周期由一系列不同的建造过程组成，建造过程表现为生命周期的一个阶段。

例如，default 生命周期拥有下面的建造过程（要获得完成的建造过程的列表 ，参考 “生命周期参考”）：

• validate – 检查项目的正确性和所需的信息是否有效
• compile – 编译项目的源代码
• test – 使用适合的单元测试框架来测试编译后的源代码。这些测试不需要代码被打包或者部署
• package – 将编译后的代码打包成为可分发的格式，例如一个JAR
• integration-test – 根据需要，处理和部署包到一个环境，那里进行集成测试
• verify – 执行一些检查，验证包是否有效并且符合质量要求
• install – 安装包到本地仓库，为让其他的项目可以依赖
• deploy – 在一个集成获得发行的环境完成，拷贝最终的包到远程仓库，与其他的开发者或者项目共享

这些建造过程（增加的其他建造过程没有在这里展示）按照一定的顺序执行，来完成default生命周期。上面给出的建造过程，这表示当default生命周期被使用，Maven将首先检查项目，然后尝试编译源代码，运行相关的测试，打包二进制文件，运行集成测试，验证包，安装验证后的包到本地仓库，然后在一个指定的环境部署安装的包。

要完成上面所有的任务，你仅仅需要调用最后的建造过程，在这个例子中，就是 deploy :

mvn deploy

这是因为你调用这个建造过程，不仅仅指定的建造过程被执行，哪些排在该建造过程前面的所有建造过程都会被执行。因此，执行

mvn integeration-test

将执行所有在它之前的建造过程（validate，compile，package，等等）。

这个生命周期还有很多建造过程，将在下面的章节讨论。

同样要注意的是，同样的命令可以在一个多模块的情景中使用（例如，一个项目有一个或者多个子项目）。例如：

mvn clean install

这个命令也会在所有的子项目中执行 clean, 然后是 instlal （包括所有前面的步骤）。

++ 建造过程是由一组目标组成

然而，构建过程负责建造生命周期的一个具体的步骤，以何种方式履行这些责任可能有所不同，因此，通过声明一些目标来绑定到这些建造过程的方法来完成。

一个目标表现为一个具体的任务（细于建造过程）有利于项目的建造和管理。它可以被绑定到零到多个建造过程。没有绑定到建造过程的目标可以在建造生命周期之外以直接调用的方式执行。执行的顺序依赖于目标的顺和被调用的建造过程s。例如，考虑下面的命令。clean 和 package 参数一个建造过程，而 dependency:copy-dependencies 是一个目标。

mvn clean dependency:copy-dependencies package

clean 过程首先被执行（这表示clean生命周期签名的所有前面的过程都被执行，加上 clean 本身），然后是 dependency:copy-dependencies 目标，最后执行 package 过程（default生命周期所有前面的过程被执行，包括package本身）。

此外，如果一个目标被绑定到多个建造过程，这个目标将在所有这些过程中被调用。

一个建造过程可以被绑定零个或者多个目标。如果一个建造过程没有绑定任何目标，那么这个建造过程将不会被执行。但如果绑定了一个获得多个目标，它将执行所有的目标（注意：在 Maven 2.0.5 和以上的版本，多个绑定到同一个过程的目标是按照POM里面声明的顺序来执行，然而，同一个插件的多个实例并不会被支持。在Maven 2.0.11 和以上的版本，同一个插件的多个实例被分组执行和排序）。

+ 设置你的项目让其使用建造生命周期

建造生命周期用起来很简单，但当你给一个项目构造一个Maven建造，你如何给这些建造过程赋予任务呢？

++ 打包

首先，最通用的方式，通过POM的元素 给你的项目设置打包。有效的打包值分别是 jar, war, ear 和 pom。如果没有指定打包值，缺省是 jar。

每一种打包都包含一系列的目标，绑定到一个具体的过程。例如， jar 打包将绑定下面的目标到 default 生命周期的建造过程。

• process-resources resources:resources
• compile compiler:compile
• process-test-resources resources:testResources
• test-compile compiler:testCompile
• test surefire:test
• package jar:jar
• install install:install
• deploy deploy:deploy

这几乎是标准绑定的集合；然而，有些打包的处理是很不一样的。例如一个项目是纯 metadata（打包值是 pom），仅仅绑定目标到 install 和 deploy 过程（要获得一个完成的列表，关于一些打包类型的目标到建造过程，参考生命周期参考）。

注意，为了让一些打包类型有效，你需要在你的POM的段中包含一个具体的插件，并且给插件指定true。
一个插件的例子，需要Plexus 插件，它提供一个 plexus-application 和 plexus-service 打包。

++ Plugins

第二种增加目标到建造过程的方法就是在你的项目中配置插件。插件是成品，它给Maven提供目标。一个插件可以有一个或者多个目标，每一个目标表现该插件的一种能力。例如 Compiler 插件有两个目标：compile 和 testCompile。前一个编译你的主要源代码，后一个编译你的测试的代码。

在后面你将看到，插件可以获得信息，指明哪些生命周期过程绑定哪些目标。注意的是，仅仅增加给它自己增加插件是不够的，还需要指明哪些目标是你的建造的一部分。

配置好的目标将增加到已经绑定到生命周期的目标。如果不止一个目标绑定到某个过程，首先执行的是来自打包的，然后是哪些在POM中配置的。注意，你可以使用元素获得对特定的目标顺序的更多控制。

例如，Modello插件缺省绑定它的目标 modelo:java 到生成源代码的 过程（注意： modello:java 目标生成 Java 源代码）。因此使用 Modello 插件，使用它从一个模型和组合到构建中，你需要增加下面的内容到POM的的 段。

…
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<configuration>
<models>
<model>src/main/mdo/maven.mdo</model>
</models>
<version>4.0.0</version>
</configuration>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
</plugin>
…

元素放在那个地方，让你可以根据需要使用不同的配置运行同一个目标多次。单独执行也可以得到一个ID，这样，在继承或配置文件，你可以控制的目标设定是否合并，变成为一个额外的执行申请。

当匹配一个具体过程的多个executions给出，他们将按照POM中指定的顺序执行，继承的executions将首先运行。

现在，在 modello:java 的例子中，仅仅在 generate-sources 过程中有意义。但有些目标不仅仅能在一个过程中使用，缺省这可能是不合理的。对于这个，你可以自己指定过程。例如，你有一个目标 display:time ，在命令行上显示当前时间，你想让它运行在 process-test-resources 过程中，来指明什么时候测试开始。这个配置如下：

…
<plugin>
<groupId>com.mycompany.example</groupId>
<artifactId>display-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>process-test-resources</phase>
<goals>
<goal>time</goal>
</goals>
</execution>
</executions>
</plugin>
…

+ 生命周期参考

下面列出default，clean 和 site 三个生命周期的所有建造过程，根据指定的点，执行的顺序和列出的顺序一致。

++ Clean Lifecycle

• pre-clean 在实际的项目清理前执行。
• clean 清理上次建造过程中产生的所有文件。
• post-clean 在项目清理后执行。

++ Default Lifecycle

• validate 检查项目是否正确，所需要的信息是否有效。
• initialize 初始化建造的状况，例如设置属性或者创建目录s。
• generate-sources 生成一些编译时包含的源代码。
• process-sources 处理源代码，例如过滤一些值。
• generate-resources 生成源代码。
• process-resources 处理和拷贝资源到目标目录，为打包做准备。
• compile 编译源代码，放入目标目录。
• process-classes 对编译后的文件的后期处理，例如对Java的类进行字节码增强。
• generate-test-sources 生成测试代码。
• process-test-sources 处理测试代码，例如过滤某些值。
• generate-test-resources 创建测试资源。
• process-test-resources 处理和拷贝资源到目标目录。
• test-compile 编译测试代码，放入测试目标目录。
• process-test-classes 对编译后的生成的测试文件进行后期处理，例如对Java类进行字节增强。Maven 2.0.5 和以上。
• test 使用测试框架进行单元测试。这些测试不需要代码打包或部署。
• prepare-package 打包前的准备。根据具体需要。通常是解包，处理不同包的不同版本。
• package 打包编译后的代码，以可发布的格式，例如一个JAR。
• pre-integration-test 集成测试前的准备。可能包括设置需要的环境。
• integration-test 处理和部署包到一个可以进行集成测试的环境。
• post-integration-test 集成测试后处理。可能包含清理环境的操作。
• verify 检验包的有效性，是否符合质量的要求。
• install 在本地仓库安装包，给使用这个依赖的本地项目使用。
• deploy 在一个集成或者发行环境中完成。拷贝最终的包到远程仓库，共享给其他的开发者和项目。

++ Site Lifecycle

• pre-site 在站点文档生成前执行。
• site 生成项目的站点文档。
• post-site 在站点文档生成后执行，准备站点的俄部署。
• site-deploy 部署生成的站点文档到远程的Web服务器。

+ 内建的生命周期绑定

缺省，一些过程拥有绑定到本身的目标。对于default生命周期，这些绑定依赖打包值。下面是一些 目标到建造过程的绑定。

++ Clean Lifecycle Bindings

• clean clean:clean

++ Default Lifecycle Bindings – Packaging ejb / ejb3 / jar / par / rar / war

• process-resources resources:resources
• compile compiler:compile
• process-test-resources resources:testResources
• test-compile compiler:testCompile
• test surefire:test
• package ejb:ejb or ejb3:ejb3 or jar:jar or par:par or rar:rar or war:war
• install install:install
• deploy deploy:deploy

++ Default Lifecycle Bindings – Packaging ear

• generate-resources ear:generateApplicationXml
• process-resources resources:resources
• package ear:ear
• install install:install
• deploy deploy:deploy

++ Default Lifecycle Bindings – Packaging maven-plugin

• generate-resources plugin:descriptor
• process-resources resources:resources
• compile compiler:compile
• process-test-resources resources:testResources
• test-compile compiler:testCompile
• test surefire:test
• package jar:jar and plugin:addPluginArtifactMetadata
• install install:install and plugin:updateRegistry
• deploy deploy:deploy

++ Default Lifecycle Bindings – Packaging pom

• package site:attach-descriptor
• install install:install
• deploy deploy:deploy

++ Site Lifecycle Bindings

• site site:site
• site-deploy site:deploy

++ References

完整的Maven生命周期在模块 maven-core 文件components.xml中定义，可通过 Maven 2.2.0 和 Maven 3.0.x 的 SVN分支查看。

m2elipse是第一个，也是最成熟的一个项目，集成 Maven 到 Eclipse IDE。在 EPL 1.0 下发行。

特点包括：

• 在Eclipse内部进行Maven建造
• 基于Maven的pom.xml来进行Eclipse的依赖管理
• 从Eclipse工作空间解释Maven的依赖，无须安装到本地Maven仓库
• 从远程仓库自动下载需要的依赖和源代码
• 提供的向导，支持创建新Maven项目，pom.xml和为已有的项目提供Maven支持
• 在远程仓库上快速搜索依赖
• 根据类和包的名字，查询需要的依赖和JARs，在Java编辑器内快速修整
• 与其他的Eclipse工具集成，例如 WTP, AJDT, Mylyn, subclipse 等

已迁移为 Eclipse 的 m2e 。

Eclipse IAM

Eclipse IAM 一个新的 Apache Maven 插件，用新的方法来集成 Maven 到 Eclipse IDE 和其他的 Eclipse 插件（JDT，WTP，Candy for Appfuse，…）一起，同样，让其他的 Eclipse 插件开发者方便的访问 Maven 的功能部件。

本地时间分发

操作系统将时间分发给应用程序

SWT UI 线程

UI有自己的独立的线程，Display 里创建。

应用的主线程负责负责处理 event loop，SWT 应用一般都有下面对结构：

public static void main(String[] args){
Display display = new Display();
Shell shell = new Shell(display);
shell.open();
// start the event loop. We stop when th euser has done
// something to dispose our window.
while(!shell.isDisposed()) {
if(!display.readAndDispatch()) {
display.sleep();
}
}
display.dispose();
}

在一个非UI 线程那里执行代码

同步
syncExec(Runnable)

非UI线程需要从 UI 代码那里获得返回值，或者 在返回到线程之前，确保 runnable 运行完成。

异步
asyncExec(Runnable)

在应用程序需要执行一些UI操作，并不依赖操作的完成再继续。

下面是一个使用这些方法的演示：
// do time-intensive computations
...
// now update the UI. We don't depend on the result,
// so use async.
display.asyncExec (new Runnable () {
public void run () {
if (!myWindow.isDisposed())
myWindow.redraw ();
}
});
// now do more computations
...

一个好的练习，使用 asyncExec 在你的 runnable 里面检查 你的 widget 是否已经被销毁。由于在UI线程内部，调用asyncExec和你的runnable的执行时间内，其他的事情可能发生，因此，你不能确认在你的runnable执行期间，你的widget是什么状态。

工作台和线程

当你从底部往上，实现一个 SWT 应用，由于你控制了event loop 的创建和fork计算线程的决定，线程的规则就变得非常明确。

当你将插件的代码发布到工作台，事情就有一点复杂了。当使用平台UI类s，下面的规则可以被考虑成“承诺的规则“，虽然随着版本的更新，这些规则会有一些异常：

• 一般情况下，你增加到平台的任何工作台UI扩展，都在工作台的UI线程内执行，除非它们与线程s或者背景工作s都特别相关（例如背景工作进度表示）。
• 如果你从工作台那里接收到一个事件，但不敢保证，它在工作台的UI线程内执行。查阅javadoc里面的特定的类，这个类定了监听器或者事件。如果没有描述线程的相关文档，并且该类明显是一个UI相关的测类，你可以期望这个事件在工作台线程内到达。
• 同样，一个平台UI库不需要考虑线程安全，否则特别给它做文档。注意，大多数的平台UI类从触发事件的调用线程分发监听器。工作台和JFace API的调用不检查调用者是否在UI线程内。如果你调用从一个非UI线程里面调用一个触发事件的方法，你的插件将产生一个问题。这种情况，SWT触发一个SWTException。一般情况下，避免从另一个线程那里调用平台UI代码，除非javaodc特别允许。
• 如果你的插件 fork一个计算线程或者使用一个工作台的job，必须使用 Display 的 asyncExec(Runnable) 或者 syncExec(Runnable)方法（为工作台，JFace或者SWT调用任意API），除非相关的API特别允许被背景线程call-in。
• 如果你的插件使用JFace的IRunnableContext接口调用一个进度监视器和运行一个操作，它提供一个参数，指明是否为运行的操作fork一个计算线程。