Shale 不是什么?Shale 不是打包好的有编制好的文档并经过严格测试的产品也没有附带自动安装程序和优雅的管理界面那么 Shale 到底是什么呢?Brett McLaughlin 在本文中将揭开这个 Struts 后代的面纱在本文中Brett 解释了 Shale 是什么Shale 与 Struts 框架的不同之处以及如何在开发环境中安装和设置它
在过去 年间出现的所有 Web 框架中Jakarta Struts 是 Java&#; 开发人员使用得最多的一种框架因此其后代的问世是一件值得注意的事情虽然 Shale 还不是最流行的框架也不是最为人熟悉的框架但是出自名门的背景仍给人以深刻印象更令人兴奋的是Shale 并不仅仅是 Struts 的重大升级和新的发行版:它彻底更新了 Struts 中的很多核心原则并且加入了 Web 开发中最新的思想
您将了解到Shale 与 Struts 的背离是一柄双刃剑一方面Shale 是经过精心设计的 Struts 的后代Shale 的创立者综合考虑了 Struts 的优点和不足提出可与其前辈媲美的下一代框架另一方面正如您很快就可以在这个系列中看到的一样Shale 是 一种完全不同于 Struts 的框架其中隐含着很多新的开发工作!
Shale 不仅仅是 Struts 的又一个修正版它已扩展到超出 Struts 所能达到的高度它包含 Java Web 程序设计中一些最重要的最近的开发成果包括 JSP Standard Tag Library(JSTL)和 JavaServer Faces(JSF)并建立在这些开发成果之上Shale 完全应该被看作是与 Struts 不同的一种框架在这个系列中我将还 Shale 框架以本来面目在这个月的文章中将首先对 Shale 与 Struts 之间的区别作一个概述然后带您体验安装 Shale 并测试安装情况的步骤最后我将给出一些思想令您能进一步参与到 Shale 项目(它是开放源码的)中并提供一些相关的信息整个系列的目的就是要向您展示如何安装 Shale 以及如何使用 Shale 构建和开发项目同时很少涉及 Shale 的前辈即 Struts 框架
评价 Shale
任何新的 Web 开发框架要想在这个竞争已经很激烈的领域占得一席之地最好能够经受住巨大压力下的评测好消息是Shale 独力经受住了细致的考察但是坏消息是由于 Shale 完全是对 Struts 重新构建的产物因此必须重新编写和重新测试您所有基于 Struts 的代码以便实现这些代码您将花同样多的精力来编写一个新的 Shale 应用程序或将一个 Struts 应用程序转换成 Shale 应用程序就好像 Shale 与 Struts 完全无关一样
所以接下来我们忍不住要问为什么还要采用 Shale 呢?为了得出答案我首先解释一下 Shale 的伟大之处 —— 这在很大程度上是由于它的 Struts 血统但这又不是惟一的原因 —— 然后讨论 Shale 之所以没有 被发布为 Struts 框架的重要修正版的两大原因这样您就会更好地理解从 Shale 身上可以得到什么这将有助于评价使用这种下一代的框架是否值得
Struts 血统
Shale 重用了大量的 Struts 代码基并声称 Struts 是它的 父 框架因此如果您要相信 Shale 的价值就得相信 Struts 的价值首先Struts 作为第一个真正意义上的 Web 开发框架拥有巨大的价值据 Shale 和 Struts 网站报道第一批代码是在 年 月提交给 Struts CVS 存储库的而Struts 是在 年末才发布的当很多开发人员正在艰难地使用 JavaServer Pages(JSP)和不断变化的 servlet 规范时Struts 提供了一种易于使用的 Model 方法来构建基于 servlet 和 JSP 的 Web 应用程序换句话说Struts 使 Web 开发人员可以开发健壮的 Web 应用程序而不必精于日志记录分布式计算JDBCServletJSPJNDIRMI 和 大量其他的 API 和技术
接下来Struts 要做的事情就是保持它的强大性:从写出第一批代码开始Struts 连续 年一直是最流行的 Web 开发框架之一至今它仍然是人们口中的谈资笔下的素材使用得不比任何竞争对手少由于 Struts 是如此流行如此长寿如今它已经有丰富的功能有良好的文档被广泛地支持并且易于使用在它上面进行开发和管理也很容易数千名开发人员对 Struts 邮件列表上的问题作出答复数万名开发人员试用 Struts 并报告问题这使得这些问题很容易得到修复
最后Struts 是不断发展的很多框架一开始比较强大然后就停滞不前(商业产品和开放源码项目都存在这样的现象)而 Struts 总是不断提供新的特性当您下载 Struts 时核心发行版中还包含一个健壮的确认引擎(validation engine)并且 Struts 已经与 JavaServer Faces 集成拥有广泛的标记库和一个不断发展的 Model 架构其中引入了在分布式 n层应用程序领域中最新的思想而且告诉您Struts 还紧跟程序设计中出现的新模式例如 IoC(Inversion of Control)Struts 与 WebWork 和 Spring 框架自然地集成后两者都是具有最佳血统的为使用 Web 开发中的新方法提供入口的框架
简而言之您很难发现在 Struts 中有做不成 或不支持的事所以显然我们就要问为什么 Shale 要另起炉灶呢?为什么 Shale 没有成为 Struts 的下一个版本呢?这有两个主要原因:一个原因与鲜为人知的新软件发行惯例有关另一个原因则与众所周知的 Struts 根基中的弱点有关让我们分别来考虑这两个原因
发行版辨析
要理解 Shale 为什么没有成为 Struts 的一个新的发行版首先需要理解关于新软件发行的一两件事对于一个新的软件发行版大多数用户首先看的是一组新的特性版本升级的幅度越大用户对新特性的期待就越大因此如果软件版本从 升级到 就应该有一些新的特性但是如果从版本 升级到版本 那么就应该有很多 新特性这就是为什么当一些大型产品(例如 Microsoft Word)或操作系统(例如 Windows 和 Mac OS X )出了新版本的时候用户总是对它们很挑剔对于每一个新的发行版用户总是期待有更多新的特性
由于大多数用户一味地将注意力放在特性上他们没有意识到向后兼容性(backward compatibility)才是真正最有价值的东西虽然每个人都希望 Excel 中加入新的很好的选项希望 Panther 与 iTunes 有更好的集成希望 Gnome 中对 XUL 有更好的支持但是如果那些用户现有的程序和文件在新版本下突然不能运行的话相信他们会尖叫这是血腥谋杀在这种情况下新特性毫无价值
对于 Struts 也一样一般来说Struts 的每个新版本都增加了新的特性同时保持了与之前版本的向后兼容性此外新版本的 Struts 还需要支持旧版本的 Java 平台和 Servlet 规范因为已安装的旧的 Struts 要在这些平台上运行这两个需求 —— 向后兼容性和对旧版本的 Java API 的支持 —— 对于 Shale 来说已经是一个严重的约束尤其是至少就 Java 平台而言JSF API 已经成为 Web 的中心组件虽然 Struts 也支持 JSF但是 Shale 却是完全依赖于 JSF 的 —— 这对于需要维持向后兼容性的 Struts 来说简直是不可能的
最后派生出一个像 Shale 这样的新项目同时继续在 Struts 这种已有的项目上进行开发活动这样做具有无与伦比的优势如果 Struts 只是简单地升级到 (或者 或 )并在不考虑向后兼容性的情况下实现 Shale那么对于很多人来说由此造成的移植工作将是令人痛苦的可能有人干脆连 Struts 也不再使用了即使仍然维护更旧的代码基也难于吸引开发人员花时间来修复 bug他们也不愿意为一个 遭到废弃 的或者 旧 版本的软件增加特性
由于这些原因让 Shale 成为一个全新的项目使其建立在一个新的代码基之上是很有意义的
Shale 的面向服务架构
Shale 之所以没有成为 Struts 的一个新的发行版其最后一个原因与逻辑没有关系:而是与该框架将新方法接纳到 Web 开发中的能力有关系Shale 在很多方面与 Struts 存在不同之处其中有两点最为突出:
Struts 与 JSF 集成而 Shale 则是建立在 JSF 之上
Struts 实质上是一个巨大的复杂的请求处理器;而 Shale 则是一组可以以任何方式进行组合的服务
Shale 对 JSF 的依赖性具有深远的令人惊讶的意义而且大部分情况下是积极的意义随着这个系列的深入我将深入研究这些意义在讨论其他方面之前有必要对造成 Shale 与 Struts 之间差异的第二个方面进行详细的讨论
如果您多次使用过 Struts那么会意识到它很大程度上可以看作一个请求处理器通过它可以接受请求并指示框架如何处理请求您可以指出采取哪种动作使用什么模型将哪种视图显示给用户采用什么验证规则显示哪种表单 Struts 是完全可以配置的然而所有这些的核心是一个请求处理器为每个请求提供服务这样的处理器是 Struts 中最重要也是最复杂的部分因为对于在处理一个请求的过程中涉及的所有工作它都必须进行处理或托管在 Struts 代码基中几乎没有哪一部分与这个请求处理器没有关系或不受它的影响
因此Struts 基本上难于作出改变如果想修改处理请求的方式或改变处理请求过程中各部分的顺序那么将面临巨大的困难实际上不得不重新编写 Struts 代码基更改请求处理器的行为倒是稍微可行但是大部分是不容变动的这是 Shale 试图解决的关键问题之一(如果您需要 Web 框架有那种程度的灵活性的话)
Shale 没有像 Struts 请求处理器那样的中心组件它只是一组数量很多的服务可以自由组合这些服务每个服务与其他服务之间是松散耦合的通过一组良好定义的接口(有时候实际上就是 Java 接口类有时候只是组件之间某种形式的契约)配置 Shale 的行为很容易这使得 Shale 是可扩展的灵活的甚至是 聪明的很容易更改它不费吹灰之力就可以扩展它并可以使它迅速适应新的编程方法像这样松散地组装组件或服务通常被称作面向服务的架构或简称 SOA当然这听起来有点儿玄乎不过您大可不必因此而觉得 Shale 不好!
安装 Shale
可以从逻辑上和概念上理解 Shale 与 Struts 的不同之处但是要想在脑海里弄清楚这两种伟大的框架有什么不同则需要亲自动手去实践一番很自然每一种 Web 框架首先都需要下载和安装不过幸好在这个过程中通常可以了解到很多东西那些安装和设置起来比较困难的项目和产品通常也难于配置难于在它上面进行部署并且(最坏的情况)难于长久运行虽然安装过程很难作为评价一个 Web 框架好坏的最可靠手段但是至少肯定应该成为这个标准的一部分在这一节中您将学习手动地安装 Shale对于一些难点有一定的体会并了解为了使 Shale 运行系统上需要些什么东西
注意我还提到了 Shale 的 简便安装 选项但是我强烈建议您至少试一试手动安装了解它提供的较深层的信息
先决条件
Shale 的先决条件和需求相当多和大多数与 Apache 和 Jakarta 相关的项目一样Shale 的安装要依赖于一些其他的 Jakarta 项目下面是为了使 Shale 得以运行所需的所有东西的完整列表:
Java Runtime Environment(JRE)和 Java Development Kit(JDK) 或更高版本
Java Servlet API 或更高版本
JSP 或更高版本
JSF 或更高版本
JSP Standard Tag Library(JSTL) 或更高版本
Jakarta Commons BeanUtils 或更高版本
Jakarta Commons Chain 或更高版本
Jakarta Commons Digester 或更高版本
Apache Logging 或更高版本
Apache Ant 或更高版本
Apache Ant 只是在构建 Shale 时要用到但是无论如何如果您要进行较多的 Java 开发那么系统上还是需要(很可能已经有了)一个版本的 Ant如果想跟蹤 Shale 中的 bug那么需要 FindBugs 或更高版本和 JUnit 或更高版本由于在第 部分中我只是讨论 Shale 的安装和使用因此您还不必关心 FindBugs 或 JUnit除非您想早点儿装上这两个项目
附件和它们的依赖项
和 Struts 一样Shale 还有一些附件(在 Shale 中常被称作可选 Shale 组件)这些附件各自又有其依赖项:
Jakarta Commons Validator 或更高版本
Spring Framework 或更高版本
Struts Tiles Framework(独立版本)
如果说这份列表显得有些长并且令人生畏的话那么没错!Shale 使用大量较低级的库helper 类实用程序组件和来自其他项目的类如果必须逐个安装这些组件配置 Shale 使用它们并将所有这些组件组装成可以部署的某种形式的话即使是最专业的开发人员也会对 Shale 望而生畏此外由于 Shale 在它的开发圈子内仍然相当年轻对于这些依赖项的获得和配置仍然有些稚嫩;然而Shale 确实是非常可行的而且不需要花费您想象中那么多的精力
首先如果您正在用某种框架从事某种 Web 开发那么应该已经有了一些作为依赖项的项目所以这份列表比它初看上去要容易管理得多例如任何 Web 开发人员都应该已经有 JRE 和 JDK也应该有一个 servlet 引擎例如 Jakarta Tomcat如果已经有一个 servlet 引擎那么也应该有 Servlet API 和 JSP 引擎另外大部分 servlet 引擎(至少就当前版本而言)都包括一个 JSTL并且很多都附带了 JSF最后大多数开发人员很可能在他们的机器上已经安装了 Ant因此这份列表很快就只剩下这些了:
JSF 或更高版本 (servlet 引擎中可能已经附带了)
JSTL 或更高版本 (servlet 引擎中可能已经附带了)
Jakarta Commons BeanUtils 或更高版本
Jakarta Commons Chain 或更高版本
Jakarta Commons Digester 或更高版本
Apache Logging 或更高版本
考虑到 Tapestry 实际上提供了将它的所有依赖项附带下载的选项因此 太多依赖项 的问题很快就不成为问题了
现在您已经知道了大概现在我们来看看下载安装和配置 Shale 及其依赖项的步骤
下载 Shale
要下载 Shale可访问 Shale 项目主页您可以看到一个 Shale Download 区域其中有 Shale 框架的每晚构建的链接单击这个链接便可以进入如图 所示的一个站点:
图 来自 Shale CVS 存储库的每晚构建
为了使 Shale 运行需要下载 framework 文件和 dependencies 文件例如在撰写本文时我下载了以下两个文件:
shaleframeworkzip
shaledependencieszip
当然如果您需要或者更愿意下载 targz 版本那么可以不选择 zip 版本而选择 targz 版本由于 Shale 的开发还在进行中目前还没有发行的构建因此您应该尽量下载最近的每晚构建(具有最近的日期)
下载完这两个文件后首先解压这两个归档文件对于核心框架解压后可以得到一个具有形如 shaleframework/ 的名称的文件夹;对于 dependencies 归档文件解压后可以得到一个名为 lib/ 的文件夹将核心框架目录 shaleframework/ 转移到您希望保存 Java 项目的地方例如在我的系统上我将 shaleframework/ 移动到 /usr/local/java 目录中接下来将 lib/ 目录移动到 Shale 目录中所以最后的目录结构与 shaleframework/lib/ 类似
添加 Shale 库到 Web 应用程序中
下一步是将所有 Shale JAR 文件和库添加到 Web 应用程序可以访问和使用它们的位置步骤如下:
如果在 servlet 引擎中没有包含 JSF那么将 shaleframework/lib/jsfri/jsfapijar 和 shaleframework/lib/jsfri/jsfimpljar 复制到应用程序的 WEBINF/lib 目录中
将 shalecorejarshaleclayjarshaletilesjar 和 tilescorejar 从 shaleframework/dist/ 目录复制到 Web 应用程序的 WEBINF/lib 目录
将以下 Shale 依赖项复制到 Web 应用程序的 WEBINF/lib 目录:
o shaleframework/lib/commonsbeanutils/commonsbeanutilsjar
o shaleframework/lib/commonschain/commonschainjar
o shaleframework/lib/commonsdigester/commonsdigesterjar
o shaleframework/lib/commonslogging/commonsloggingjar
o shaleframework/lib/commonsvalidator/commonsvalidatorjar
如果要使用 Shale 的 Spring 集成特性那么将 shalespringjar 从 shaleframework/dist/ 复制到 Web 应用程序的 WEBINF/ 目录要完成这个步骤还必须确保 Spring 的打包 JAR 文件也在 Web 应用程序的 WEBINF/lib 目录中这个 JAR 文件名为 springjar如果您还没有这个文件的话可以在 shaleframework/lib/shaleframework/ 目录中找到它
如果正在使用 Java 那么将 shaletigerjar 从 shaleframework/dist/ 复制到 Web 应用程序 的 WEBINF/lib 目录中只有在使用 Java 的时候才需要执行这一步;否则servlet 引擎和使用 Shale 的 Web 应用程序就会出问题
再往后走就开始复杂起来(是的这些复制操作是较容易的一部分)接下来的事情未必都要用最难的方式去做至少我应该让您有机会选择 试试容易的方法使 Shale 在系统上运行这个任务的确存在捷径;您已经知道手动设置 Shale 的过程比较复杂接下来有必要看看 简便 方法
更容易的方法
重新访问 Shale 下载站点并下载名称类似于 shalestarterzip 的 starter 应用程序解压这个归档文件将得到一个名为 shalestarter/ 的目录这是一个基本上配置好的 Shale Web 应用程序用于帮助避免前一节详细介绍的复制和配置工作首先要做的是将 shalestarter/ 目录重新命名成应用程序以后要使用的名称例如可以将它命名为 firstshale/进入 firstshale/ 目录在这里可以看到一些文件和子目录
在 firstshale/ 目录中创建一个名为 buildproperties 的新文件通过这个文件可以定制如何构建 Shale starter 应用程序并确保该应用程序适合您的环境设置清单 展示了一个基本的 buildproperties 文件可以根据自己的环境对其进行定制
清单 Shale starter 应用程序的示例 buildproperties
# Basic project information
pyright=My project Copyright ?
projectname=My First Shale Application
projectvendor=IBM DeveloperWorks
projectvendorid=comibmdw
# Java package and context path for servlet engine
projectpackage=comibmdwfirstShale
projectpath=firstshale
# Directory for Shale distribution change this for your system
shaledir=/usr/local/java/shaleframework
# Directory for all your libraries change this for your system
libdir=/usr/local/java/shaleframework/lib
根据系统设置好这些属性后便可以运行 antShale starter 应用程序开始构建 并(假设已经正确地设置了路径)创建一个示例应用程序如果有问题则构建脚本输出错误消息;这些错误消息都描述得很清楚所以您应该可以更正任何错误
构建过程的最后将生成一个名为 target/ 的新目录进入这个目录可以看到一个名为 firstapp(即您在 buildproperties 中为项目指定的名称)的子目录大多数 servlet 引擎都允许将这个目录整个地复制到 servlet 引擎的 webapps/ 目录例如我使用的是 Tomcat于是我将构建脚本创建的整个 firstshale 目录复制到 /usr/local/java/tomcat/webapps
构建 WAR 文件
如果使用的 servlet 引擎要求提供 WAR 文件那么可以使用相同的 Shale starter 应用程序的构建文件只需略微修改一下由于还没有为这个 Shale 应用程序编写任何 Java 文件当您请求一个 WAR 文件时构建脚本将出现错误(在 buildxml 中有查找文件的 JavaScript 命令但是没有找到任何文件)为了修复这个问题打开 buildxml 文件找到以 javadoc 开头且如下所示的代码:
description="Create JavaDocs">
sourcepath="${src.java.dir}" destdir="${build.docs.dir}"
author="false"
private="true"
version="true"
source="${project.source}"
packagenames="${project.package}.*"
windowtitle="${project.name} (Version ${project.version})"
doctitle="${project.name} (Version ${project.version})"
bottom="${pyright}">
includes="**/*.gif"/>
现在，注释掉 javadoc 任务，如下所示:
description="Create JavaDocs">
<
sourcepath="${src.java.dir}" destdir="${build.docs.dir}"
author="false"
private="true"
version="true"
source="${project.source}"
packagenames="${project.package}.*"
windowtitle="${project.name} (Version ${project.version})"
doctitle="${project.name} (Version ${project.version})"
bottom="${pyright}">
-->
includes="**/*.gif"/>
一旦开始为 Shale 应用程序开发 Java 代码，便不必这样做。tw.wINGWIT.CoM不过对于现在，这样做可以解决上述问题。保存修改后的 build.xml 并运行 ant dist。Ant 编译和装配 starter 应用程序，并在 dist/ 目录中创建一个新的 WAR 文件。例如，我运行 ant dist 后得到一个 dist/first-shale-0.1.war 文件。现在可以将这个 WAR 文件复制到 servlet 引擎的 webapps/ 目录。
测试安装情况
如果完成了以上步骤，不管选择的安装路径是什么，都应该可以启动 servlet 引擎并通过地址 -shale 访问 Shale 应用程序。例如，如果在本地机器上运行 Tomcat，那么最终可以访问的地址是//localhost:8080/first-shale。如果一切正常，那么应该可以看到如图 2 所示的简单页面:
图 2. Shale starter 应用程序证明一切没问题
看起来似乎做了这么多工作却所得甚少，但是要考虑到，通过打开并编辑一个简单的 build.properties 文件，可以避免大量繁杂的复制和配置工作。您将发现，从空白的 Shale starter 应用程序开始总是开发新的 Shale 应用程序最容易的方式。实际上，当在下一篇文章中开始开发 Shale 应用程序的时候，将使用空白的 starter 应用程序作为开始的基础。
Shale 用例
关于 Shale 的下载和安装就介绍到这里，不过我们还是再花点儿时间从 Shale 主下载站点下载 Shale 的用例 WAR 应用程序。找到一个文件名形如 shale-usecases-20060204.war 的文件。下载该文件，并将它放入 servlet 引擎的 webapps/ 目录，然后进入到这个 WAR。在我的系统上，访问//localhost:8080/shale-usecases-20060204/ 并得到如图 3 所示的屏幕:
图 3. Shale 用例应用程序
您应该花些时间来看看这个用例应用程序。它有关于 Shale 中 Validator 和远程报告等特性的很好的演示，并有一个简单的 Ajax 应用程序。通过浏览这些用例，您可以了解到即使是简单的 Shale 应用程序也可以做许多事情。
不过这里要提一个忠告:有些用例仍在开发中，取决于您何时下载每晚构建，可能发现有些用例不能正常工作。不过总是可以晚些时候再下载这些用例应用程序，看看有些问题是否已经被修复。虽然存在这些小问题，但是用例应用程序仍然是取得对 Shale 的基本印象的一种好途径。
深入研究 Shale！
大多数 Web 开发人员向来只是使用已有的框架(例如 Shale、Struts 或 Spring)来开发他们的 Web 应用程序，而没有做别的事情。当然这没有什么错，但是如果想理解一种框架以及它所涉及的技术，那么只能对框架本身做深入的研究。
对于 Shale(当然也包括 Struts)，通过查看框架的内部，您可以学到大量关于 servlet和 Web 开发的知识。如果想在自己的项目中使用一些 Shale 依赖项，这样做还可以获得难以置信的帮助。如果您对通过 Java 应用程序进行日志管理感兴趣，那么通过 Shale 来熟悉 Apache Logging 项目比阅读任何文章都要有效得多。对于 Jakarta Commons BeanUtils、Chain 或 Digester 项目也是一样。这些都是很好的工具，对于开发人员很有用，所以花几个星期或几个月的时间探索一下 Shale 对于这些领域是一个很好的学习经历。
由于本文是对 Shale 进行深入探讨的系列中的第一期，因此如果我不对几个对于 Shale 项目入门来说至关重要的方面进行讨论的话，就是不负责任了。
亲密接触源代码
不幸的是，关于 Shale 中涉及的开发过程的文档并不多，所以如果您想直接使用 Shale 源代码的话，需要用点儿技巧。一般来说，我这里给出的关于下载 Shale 并将它作为框架使用的说明也适用于下载 Shale 的源代码。每晚构建包含 Shale 的所有源代码，并且代码的每个目录中都有一个 build.xml 文件。
需要将下载的 Shale 的根目录下的 build.properties.sample 文件复制到一个名为 build.properties 的文件中(去掉原始文件名尾部的 “.sample”)。清单 2 展示了这个文件的一个示例，为了简洁起见，这里省略了其中一些注释:
清单 2. 示例 Shale 构建文件
# This file contains example property settings that you would use to customize
# your build environment to build the Struts Shale Library from
# source code. To use this file, make a copy of it in "build.properties" and
# customize the values as required.
# Root directory into which you have unpacked the Shale Framework release.
root.dir=${basedir}
# Fully qualified pathname of the directory into which you have unpacked
# a binary distribution of the JavaServer Faces Reference Implementation
jsfri.dir=/usr/local/jsf-1_1_01
findbugs.outputFile=${root.dir}/l
lib.dir=${root.dir}/lib
jsf.home = ${lib.dir}/myfaces
jsf-api.jar = ${jsf.home}/myfaces-api.jar
jsf-impl.jar = ${jsf.home}/myfaces-impl.jar
# The absolute or relative pathname of the Apache Struts
# distribution
struts.home = /usr/local/jakarta-struts
spring.home=${lib.dir}/springframework
findbugs.home = /usr/local/findbugs-0.8.6
为了与您的系统相匹配，需要更改这个构建文件中大部分的路径。默认情况下，${basedir} 指向运行 Ant 时所在的目录，因此如果是从下载的 Shale 的根目录下运行 Ant，那么就刚好不用改路径了。但是对于其他路径，应该改为适当的与系统相匹配的路径。例如，如果您的 JSF 参考实现在 c:/java/jsf-1_1_02 中，那么使用 jsfri.dir 目录所在的路径。大多数默认路径都适合于使用 MyFaces(请参阅 “MyFaces 还是 JavaServer Faces”)，但是当然也可以使用 Sun 的 JSF 实现，并对这些路径作相应的更改。另外还需要设置 Struts、Spring(这是可选的，对于核心 Shale 框架来说不必要)和 FindBugs 项目的路径。
Ant 登场
设置好这些文件的路径后，就可以在 Shale 的根目录中运行 Ant。但是，首先应该运行 ant download-dependencies。您当然也已经注意到，Shale 有很多 依赖项，而通过使用 Ant 自动下载这些依赖项可以为您节省很多时间，也令您轻松不少。Ant 脚本还负责设置路径，以便使 Shale 与那些依赖项连接起来。还应该运行 ant copy-jsf-ri 来处理一些特定于 JSF 的任务(具体细节不必关心，因为 Ant 会为您打点一切)。
在构建主 Shale 发行版之前，应该运行 ant clean 删除之前已有的构建后的代码。虽然这意味着整个构建时间会更长，但是可以确保所有代码将一致地构建。最后，运行 ant release，以便从头开始构建 Shale。当这个 Ant 脚本运行完成后(这要花一点儿时间)，就可以得到一个完整的、从源代码构建的 Shale 发行版。
关于邮件列表的只言片语
开发源码项目几乎完全是通过电子邮件(再加上 Apache bug 跟蹤数据库，在 参考资料 小节中有这方面的内容)来运作的。Shale 在这方面也是一样的，不过它仍然使用 Struts 的邮件列表。如果在使用 Shale 时有什么疑问，可以发送电子邮件到 us。但是当您开始开发真正的 Shale 内部组件时，应该将电子邮件发送到 d。不管将电子邮件发送到哪里，都应该以 “[shale]” 开头，这样别人一下子就明白您是要问关于 Shale 的问题，而不是关于 Struts 的问题。预期在几个月后，当 Shale 开始成为独立的项目时，它也会有它自己的邮件列表。
这里稍微提醒一下，尤其是在发送电子邮件到开发列表的时候:做好自己的工作，问题要有的放矢。那些飘忽不定、模稜两可或缺乏思想的邮件很可能不会收到回复。如果您到处发送 “我想学习 Shale，请给我发送一些例子应用程序” 之类的邮件，甚至还可能得到粗鲁的回答。虽然这种提醒看上去有些傻，但事实就是这样。开发列表中总是充斥着这一类的问题，这些问题都是不受欢迎 的。通常，花点儿时间认真地斟酌您的问题，解释一下您使用的平台和软件的版本，并说明您已经试过了一些常用的步骤。这样一来，您的请求才会得到尊重并受到欢迎，也就更容易得到答案。开发人员的列表并不是令人生畏的，但最起码这样做显得您尊重别人。
结束语
这个关于 Shale 的系列中的第一期文章说明，Shale 并不适合每一个人。Shale 没有提供一个打包好的、有编制好的文档并经过良好测试的产品，也没有附带自动安装程序和优雅的管理界面，这些都是很多 Web 开发人员期待 Tapestry 时代能提供的东西。虽然在以后版本的框架中会体现这些东西(除了完全打包)，但目前 Shale(从 2006 年初起)仍在开发过程中，并且 Shale 站点也基本上将它称为处于 “alpha” 状态的项目。Shale 中使用的很多组件是稳定和成熟的，但 Shale 本身仍然很年轻。如果您不能接受一些麻烦和困惑，那么可能会想过一年左右再开始使用它。
另一方面，如果您是一名对 Web 开发的前沿技术感兴趣的 Java 开发人员，那么真应该看看 Shale 项目。虽然安装 Shale 并使之工作要花费更多的精力，但是它完全有条件成为特别流行的 Web 开发框架。Shale 继承了 Struts，同时也提供了一些全新的东西，这本身就值得作一番调查。对于有兴趣成为开放源码项目中的一员的开发人员，Shale 也是值得投入精力的一个项目。
