Shale不是什么？Shale不是打包好的、有编制好的文档并经过严格测试的产品，也没有附带自动安装程序和优雅的管理界面。那么Shale到底是什么呢？Brett McLaughlin在本文中将揭开这个Struts后代的面纱。本文是一个由五部分组成的系列中的第一篇文章，在本文中，Brett解释了Shale是什么，Shale与Struts框架的不同之处，以及如何在开发环境中安装和设置它。

在过去5年间出现的所有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网站报道，第一批代码是在2000年6月提交给Struts CVS存储库的，而Struts 1.0是在2001年末才发布的。当很多开发人员正在艰难地使用Java Server Pages（JSP）和不断变化的servlet规范时，Struts提供了一种易于使用的Model 2方法来构建基于servlet和JSP的Web应用程序。换句话说，Struts使Web开发人员可以开发健壮的Web应用程序，而不必精于日志记录、分布式计算、JDBC、Servlet、JSP、JNDI、RMI和大量其他的API和技术。

接下来，Struts要做的事情就是保持它的强大性：从写出第一批代码开始，Struts连续6年一直是最流行的Web开发框架之一。至今它仍然是人们口中的谈资，笔下的素材，使用得不比任何竞争对手少。由于Struts是如此流行，如此长寿，如今它已经有丰富的功能，有良好的文档，被广泛地支持，并且易于使用，在它上面进行开发和管理也很容易。数千名开发人员对Struts邮件列表上的问题作出答复，数万名开发人员试用Struts并报告问题，这使得这些问题很容易得到修复。

最后，Struts是不断发展的。很多框架一开始比较强大，然后就停滞不前（商业产品和开放源码项目都存在这样的现象），而Struts总是不断提供新的特性。当您下载Struts时，核心发行版中还包含一个健壮的确认引擎（validation engine），并且Struts已经与JavaServer Faces集成，拥有广泛的标记库和一个不断发展的Model 2架构，其中引入了在分布式n-层应用程序领域中最新的思想。而且告诉您，Struts还紧跟程序设计中出现的新模式，例如IoC（Inversion of Control）。Struts与WebWork和Spring框架自然地集成，后两者都是具有最佳血统的、为使用Web开发中的新方法提供入口的框架。

简而言之，您很难发现在Struts中有做不成或不支持的事。所以显然我们就要问，为什么Shale要另起炉灶呢？为什么Shale没有成为Struts的下一个版本呢？这有两个主要原因：一个原因与鲜为人知的新软件发行惯例有关，另一个原因则与众所周知的Struts根基中的弱点有关。让我们分别来考虑这两个原因。

发行版辨析

要理解Shale为什么没有成为Struts的一个新的发行版，首先需要理解关于新软件发行的一两件事。对于一个新的软件发行版，大多数用户首先看的是一组新的特性。版本升级的幅度越大，用户对新特性的期待就越大。因此，如果软件版本从2.1升级到2.2，就应该有一些新的特性，但是如果从版本2.2升级到版本3.0，那么就应该有很多新特性。这就是为什么当一些大型产品（例如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只是简单地升级到2.0（或者3.0或4.0），并在不考虑向后兼容性的情况下实现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） 1.4或更高版本

Java Servlet API 2.4 或更高版本

JSP 2.0 或更高版本

JSF 1.1 或更高版本

JSP Standard Tag Library（JSTL） 1.1或更高版本

Jakarta Commons BeanUtils 1.7或更高版本

Jakarta Commons Chain 1.0或更高版本

Jakarta Commons Digester 1.7或更高版本

Apache Logging 1.0.4或更高版本

Apache Ant 1.6.3或更高版本

Apache Ant只是在构建Shale时要用到，但是无论如何，如果您要进行较多的Java开发，那么系统上还是需要（很可能已经有了）一个版本的Ant。如果想跟踪Shale中的bug，那么需要FindBugs 0.8.5或更高版本和JUnit 3.8.1或更高版本。由于在第1部分中我只是讨论Shale的安装和使用，因此您还不必关心FindBugs或JUnit，除非您想早点儿装上这两个项目。

附件和它们的依赖项

和Struts一样，Shale还有一些附件（在Shale中常被称作可选Shale组件），这些附件各自又有其依赖项：

Jakarta Commons Validator 1.2或更高版本

Spring Framework 1.2.2或更高版本

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 1.1或更高版本（servlet引擎中可能已经附带了）

JSTL 1.1或更高版本（servlet引擎中可能已经附带了）

Jakarta Commons BeanUtils 1.7或更高版本

Jakarta Commons Chain 1.0或更高版本

Jakarta Commons Digester 1.7或更高版本

Apache Logging 1.0.4或更高版本

考虑到Tapestry实际上提供了将它的所有依赖项附带下载的选项，因此“太多依赖项”的问题很快就不成为问题了。

现在您已经知道了大概，现在我们来看看下载、安装和配置Shale及其依赖项的步骤。

1.下载Shale

要下载Shale，可访问Shale项目主页。您可以看到一个“Shale Download”区域，其中有Shale框架的每晚构建的链接。单击这个链接，便可以进入一个站点：

为了使Shale运行，需要下载“framework”文件和“dependencies”文件。例如，在撰写本文时我下载了以下两个文件：

shale-framework-20060204.zip

shale-dependencies-20060204.zip

当然，如果您需要或者更愿意下载.tar.gz版本，那么可以不选择.zip版本，而选择.tar.gz版本。

由于Shale的开发还在进行中，目前还没有发行的构建，因此您应该尽量下载最近的每晚构建（具有最近的日期）。

下载完这两个文件后，首先解压这两个归档文件。对于核心框架，解压后可以得到一个具有形如shale-framework-20060204/的名称的文件夹；对于dependencies归档文件，解压后可以得到一个名为lib/的文件夹。将核心框架目录shale-framework-20060204/转移到您希望保存Java项目的地方。例如，在我的系统上，我将shale-framework-20060204/移动到/usr/local/java目录中。接下来，将lib/目录移动到Shale目录中，所以最后的目录结构与shale-framework-20060204/lib/类似。

2.添加Shale库到Web应用程序中

下一步是将所有Shale JAR文件和库添加到Web应用程序可以访问和使用它们的位置。步骤如下：

如果在servlet引擎中没有包含JSF，那么将shale-framework-20060204/lib/jsf-ri/jsf-api.jar和shale-framework-20060204/lib/jsf-ri/jsf-impl.jar复制到应用程序的WEB-INF/lib目录中。

将shale-core.jar、shale-clay.jar、shale-tiles.jar和tiles-core.jar从shale-framework-20060204/dist/目录复制到Web应用程序的WEB-INF/lib目录。

将以下Shale依赖项复制到Web应用程序的WEB-INF/lib目录：

shale-framework-20060204/lib/commons-beanutils/commons-beanutils.jar

shale-framework-20060204/lib/commons-chain/commons-chain.jar

shale-framework-20060204/lib/commons-digester/commons-digester.jar

shale-framework-20060204/lib/commons-logging/commons-logging.jar

shale-framework-20060204/lib/commons-validator/commons-validator.jar

如果要使用Shale的Spring集成特性，那么将shale-spring.jar从shale-framework-20060204/dist/复制到Web应用程序的WEB-INF/目录。要完成这个步骤，还必须确保Spring的打包JAR文件也在Web应用程序的WEB-INF/lib目录中。这个JAR文件名为spring.jar，如果您还没有这个文件的话，可以在shale-framework-20060204/lib/shaleframework/目录中找到它。

如果正在使用Java 5.0，那么将shale-tiger.jar从shale-framework-20060204/dist/复制到Web应用程序的WEB-INF/lib目录中。只有在使用Java 5.0的时候才需要执行这一步；否则，servlet引擎和使用Shale的Web应用程序就会出问题。

再往后走就开始复杂起来（是的，这些复制操作是较容易的一部分）。接下来的事情未必都要用最难的方式去做，至少我应该让您有机会选择试试容易的方法。使Shale在系统上运行这个任务的确存在捷径；您已经知道手动设置Shale的过程比较复杂，接下来有必要看看“简便”方法。

更容易的方法

重新访问Shale下载站点，并下载名称类似于shale-starter-20060204.zip的“starter”应用程序。解压这个归档文件，将得到一个名为shale-starter/的目录。这是一个基本上配置好的Shale Web应用程序，用于帮助避免前一节详细介绍的复制和配置工作。首先要做的是将shale-starter/目录重新命名成应用程序以后要使用的名称，例如可以将它命名为first-shale/。进入first-shale/目录，在这里可以看到一些文件和子目录。

在first-shale/目录中，创建一个名为build.properties的新文件。通过这个文件可以定制如何构建Shale starter应用程序，并确保该应用程序适合您的环境设置。清单1展示了一个基本的build.properties文件，可以根据自己的环境对其进行定制。

清单1.Shale starter应用程序的示例build.properties

# Basic project information

project.copyright=My project, Copyright ? 2006

project.name=My First Shale Application

project.vendor=IBM DeveloperWorks

project.vendor.id=com.ibm.dw

# Java package and context path for servlet engine

project.package=com.ibm.dw.firstShale

project.path=first-shale

# Directory for Shale distribution - change this for your system

shale.dir=/usr/local/java/shale-framework-20060204

# Directory for all your libraries - change this for your system

lib.dir=/usr/local/java/shale-framework-20060204/lib

根据系统设置好这些属性后，便可以运行ant。Shale starter应用程序开始构建并（假设已经正确地设置了路径）创建一个示例应用程序。如果有问题，则构建脚本输出错误消息；这些错误消息都描述得很清楚，所以您应该可以更正任何错误。

构建过程的最后将生成一个名为target/的新目录。进入这个目录，可以看到一个名为first-app（即您在build.properties中为项目指定的名称）的子目录。大多数servlet引擎都允许将这个目录整个地复制到servlet引擎的webapps/目录。例如，我使用的是Tomcat，于是我将构建脚本创建的整个first-shale目录复制到/usr/local/java/tomcat/webapps。

构建WAR文件

如果使用的servlet引擎要求提供WAR文件，那么可以使用相同的Shale starter应用程序的构建文件，只需略微修改一下。由于还没有为这个Shale应用程序编写任何Java文件，当您请求一个WAR文件时，构建脚本将出现错误（在build.xml中有查找文件的JavaScript命令，但是没有找到任何文件）。为了修复这个问题，打开build.xml文件，找到以“javadoc”开头且如下所示的代码：

<!-- ===================== Generate Documentation ======================== -->

<target         name="javadocs" depends="compile"

description="Create JavaDocs">

<mkdir         dir="${build.docs.dir}"/>

<javadoc

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="${project.copyright}">

<classpath refid="compile.classpath"/>

</javadoc>

<copy        todir="${build.docs.dir}">

<fileset     dir="${src.java.dir}"

includes="**/*.gif"/>

</copy>

</target>

现在，注释掉 javadoc 任务，如下所示：

<!-- ===================== Generate Documentation ======================== -->

<target         name="javadocs" depends="compile"

description="Create JavaDocs">

<mkdir         dir="${build.docs.dir}"/>

<

<javadoc

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="${project.copyright}">

<classpath refid="compile.classpath"/>

</javadoc>

-->

<copy        todir="${build.docs.dir}">

<fileset     dir="${src.java.dir}"

includes="**/*.gif"/>

</copy>

</target>

一旦开始为Shale应用程序开发Java代码，便不必这样做。不过对于现在，这样做可以解决上述问题。保存修改后的build.xml并运行antdist。Ant编译和装配starter应用程序，并在dist/目录中创建一个新的WAR文件。例如，我运行antdist后得到一个dist/first-shale-0.1.war文件。现在可以将这个WAR文件复制到servlet引擎的webapps/目录。

测试安装情况

如果完成了以上步骤，不管选择的安装路径是什么，都应该可以启动servlet引擎并通过地址http://your.host.name/first-shale访问Shale应用程序。例如，如果在本地机器上运行Tomcat，那么最终可以访问的地址是http://localhost:8080/first-shale。如果一切正常，那么应该可以看到一个简单页面。

看起来似乎做了这么多工作却所得甚少，但是要考虑到，通过打开并编辑一个简单的build.properties文件，可以避免大量繁杂的复制和配置工作。您将发现，从空白的Shale starter应用程序开始总是开发新的Shale应用程序最容易的方式。实际上，当在下一篇文章中开始开发Shale应用程序的时候，将使用空白的starter应用程序作为开始的基础。

Shale用例

关于Shale的下载和安装就介绍到这里，不过我们还是再花点儿时间从Shale主下载站点下载Shale的用例WAR应用程序。找到一个文件名形如shale-usecases-20060204.war的文件。下载该文件，并将它放入servlet引擎的webapps/目录，然后进入到这个WAR。在我的系统上，访问http://localhost:8080/shale-usecases-20060204/并得到一个页面：

您应该花些时间来看看这个用例应用程序。它有关于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}/find-bugs.html

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时有什么疑问，可以发送电子邮件到user@struts.apache.org。但是当您开始开发真正的Shale内部组件时，应该将电子邮件发送到dev@struts.apache.org。不管将电子邮件发送到哪里，都应该以“[shale]”开头，这样别人一下子就明白您是要问关于Shale的问题，而不是关于Struts的问题。

预期在几个月后，当Shale开始成为独立的项目时，它也会有它自己的邮件列表。

这里稍微提醒一下，尤其是在发送电子邮件到开发列表的时候：做好自己的工作，问题要有的放矢。那些飘忽不定、模棱两可或缺乏思想的邮件很可能不会收到回复。如果您到处发送“我想学习Shale，请给我发送一些例子应用程序”之类的邮件，甚至还可能得到粗鲁的回答。虽然这种提醒看上去有些傻，但事实就是这样。开发列表中总是充斥着这一类的问题，这些问题都是不受欢迎的。通常，花点儿时间认真地斟酌您的问题，解释一下您使用的平台和软件的版本，并说明您已经试过了一些常用的步骤。这样一来，您的请求才会得到尊重并受到欢迎，也就更容易得到答案。开发人员的列表并不是令人生畏的，但最起码这样做显得您尊重别人。

结束语

这个关于Shale的系列中的第一期文章说明，Shale并不适合每一个人。Shale没有提供一个打包好的、有编制好的文档并经过良好测试的产品，也没有附带自动安装程序和优雅的管理界面，这些都是很多Web开发人员期待Tapestry时代能提供的东西。虽然在以后版本的框架中会体现这些东西（除了完全打包），但目前Shale（从2006年初起）仍在开发过程中，并且Shale站点也基本上将它称为处于“alpha”状态的项目。Shale中使用的很多组件是稳定和成熟的，但Shale本身仍然很年轻。如果您不能接受一些麻烦和困惑，那么可能会想过一年左右再开始使用它。

另一方面，如果您是一名对Web开发的前沿技术感兴趣的Java开发人员，那么真应该看看Shale项目。虽然安装Shale并使之工作要花费更多的精力，但是它完全有条件成为特别流行的Web开发框架。

Shale继承了Struts，同时也提供了一些全新的东西，这本身就值得作一番调查。对于有兴趣成为开放源码项目中的一员的开发人员，Shale也是值得投入精力的一个项目。

如果您真的准备冒一次险，那么比起本期关于安装和基本设置的讨论来，这个系列还有多得多的内容。在下一篇文章中，我将解释Shale背后的一些原则，以及如何编写Shale应用程序。您还将在我的指导下体验Struts starter应用程序，并学习如何使用它作为开发自己应用程序的基础。所以下个月请继续关注更多关于Shale的内容吧！