Written by Srikanth Shenoy November 2003
Translated by jinfeng wang 2005年三月
原文地址：http://www.theserverside.com/articles/article.tss?l=MavenMagic
本文的翻譯已經原作者同意，轉載請保持原文。如有問題和意見可以和原作者或我聯系。
Part 1: http://m.tkk7.com/jinfeng_wang/archive/2005/03/11/1956.html
Part 2: http://m.tkk7.com/jinfeng_wang/archive/2005/03/14/2074.html
Now I will show you how to use the XDoclet plugin to generate the tld automatically. I will be using XDoclet version 1.2 Beta3. Consider the declaration in the tld file for a tag say
MyTag.
下面我將演示XDoclet是如何自動生成tld文件的。我將使用XDoclet的1.2 Beta3版本。這里假設將在tld文件中聲明MyTag的tag。
<tag>
<name>mystuff</name>
<tag-class>foobar.webapp.MyTag</tag-class>
<body-content>JSP</body-content>
<attribute>
<name>locale</name>
<required>false</required>
<rtexprvalue>false</rtexprvalue>
</attribute>
</tag>
It is okay to have a readymade tld for frameworks such as Struts. However when you are developing your own tags either by customizing the existing tags or from scratch, it is natural that they change and evolve constantly during development. It can be time consuming to manually synchronize the tag code and its declaration in the tld. XDoclet is designed to ease such burdens. In the source code for the MyAppTag, add @jsp.tag name="myapptag" body-content="JSP" in its class comments section. For each of the tag attributes, add a @jsp.attribute on the getter method for that attribute. For instance, add @jsp.attribute required="false" rtexprvalue="false" to the comments on the getMyMessage method to represent that myMessage is a tag attribute. Next you invoke the webdoclet goal from the xdoclet plugin in maven.xml as shown in Listing 12. XDoclet also gives you provision to generate the web.xml too. Let us look at the maven.xml for the Web project in its entirety.
在項目中使用現有的諸如Structs的tld框架是可以的，但是有時候通過定制現有tag或者完全重寫的方式，開發自己的tag，顯然在開發的過程中他們會經常的變化。手工保持tag代碼和tld文件中聲明的同步是非常耗時的，XDoclet則可以幫你減輕這里的工作。在MyAppTag的源代碼中，在class的注釋部分加入@jsp.tag name="myapptag" body-content="JSP"。對于每一個tag屬性，請在屬性的getter方法前面前添加@jsp.attribute。例如在表示myMessage是tag屬性的getMyMessage方法的前面加入@jsp.attribute required="false" rtexprvalue="false"。下面將會如表12所示在maven.xml中調用xdoclet插件的webdoclet方法。XDoclet頁可以幫你生成web.xml，我們來看看Web項目中的完整的maven.xml吧。
Listing 12 maven.xml for the Web Project
表12 Web項目的maven.xml
<project default="foobar-dist" xmlns:m="jelly:maven"
xmlns:ant="jelly:ant">
<goal name="foobar-dist">
<attainGoal name="war:install" />
</goal>
<preGoal name="war:init">
<attainGoal name="xdoclet:webdoclet"/>
</preGoal>
</project>
|
NOTE: You have to add the XDoclet web module in the dependency section for the project.xml as follows.
注意：你必須在project.xml的依賴部分如下加入XDoclet的Web module（譯者注：源代碼中有問題，在我的系統中需要寫成“<artifactId>xdoclet-web-module</artifactId>”，此外，還有些其他問題。）：
<dependency>
<id>xdoclet+web-module</id>
<version>1.2b4</version>
</dependency>
In addition, override the following properties in the plugin.properties file for XDoclet under the Maven plugins folder
另外，在Maven的插件目錄中找到XDoclet，如下修改plugin.properties的屬性：
maven.xdoclet.webdoclet.deploymentdescriptor.0=false
maven.xdoclet.webdoclet.jsptaglib.0.destDir=
${maven.build.dir}/${pom.artifactId}/WEB-INF/tld The first setting disables web.xml generation and the second setting sets the generated tld file location. In this article you will just be generating the tld file, but not generating the web.xml, nor the <taglib> entry for the tld file in web.xml. As a matter of fact, XDoclet does not seem to have the Maven equivalent for the following Ant script that adds the <taglib> to web.xml.
這里第一個設置禁止了Web.xml的自動生成，第二個設置了tld文件生成位置。在本文中，你將會生成tld文件，但是并不需要生成Web.xml，也不許在web.xml中添加<taglib>入口。事實上，XDoclet好像沒有Ant中將<taglib>加入到web.xml中的功能，Ant的代碼可以這樣寫：
<deploymentdescriptor servletspec="2.3" destdir="${WEBINF}" >
<taglib uri="myapptaglibs" location="WEB-INF/tld/myapp.tld" />
</deploymentdescriptor>
Another thing that I noticed in the XDoclet plugin is that the file name for the tag library definitions (tld) has to be provided in plugin.properties as follows.
我還注意到：在Xdoclet插件中，tld文件名必須在plugin.properties中如下給出：
maven.xdoclet.webdoclet.jsptaglib.0.filename=myapp.tld Otherwise the tld file is generated with the default name of taglib.tld. This does not seem right. Instead it should be set in the build script. For instance, in Ant this is done as follows
否則tld文件名將會是默認的taglib.tld，這是不正確的。它應該在build腳本中被設置。在Ant中則是這樣寫：
<jsptaglib jspversion="1.2" destdir="${WEBINF}/tld"
shortname="basic" filename="myapp.tld"/> Ideally I would like to set this like this:
我更喜歡下面的比較完美的寫法：
<dependency>
<id>xdoclet+web-module</id>
<version>1.2b4</version>
<properties>
<jsptaglib.filename>myapp.tld</jsptaglib.filename>
</properties>
</dependency> This is not a Maven defect. It just is an example showing that it takes time for third party vendors to catch up.
這并不是Maven的缺點，它是第三方插件提供者所需要注意的問題。 |
Building the EAR (構建EAR)
Up until now you have seen how to create each of the individual artifacts that go into the EAR. Finally we have reached the last part - building the EAR itself. You might imagine that since the EAR is the only artifact from the project as a whole, it should be built from the project definition at the top of the hierarchy, i.e. the Foobar-Travels folder. However that is not the case. The EAR is built as an artifact from a subproject called ear (See Figure 3). Why this anomaly? First of all, the project.xml at the Foobar-Travels project level is a template for other subprojects to extend. If it were to specify the dependencies to build the EAR, then it would have resulted in a cyclic dependency - a chicken and egg situation - when the template is extended by other subprojects. If the template were to be defined elsewhere, probably at the organization level, then the project.xml in Foobar-Travels folder could have produced the EAR but then it would not be the template for the rest of the subprojects to extend.
到目前為止，你已經了解了如何創建各將要加入到EAR中的制品，現在我們開始最后一步－構建EAR。也許你會這樣的想法：因為EAR是做為整個項目的唯一制品，那么就該在項目的最頂端構建它，例如Foobar-Travels目錄。但是事實上卻不是這樣的。EAR是做為一個單獨的子項目的制品被生成的（參考圖3）。為何這樣特別呢？首先，Foobar-Travels項目的頂層project.xml是作為各子項目的模板進行擴展的。如果在其中聲明了EAR所依賴的包，那么在模板被其他子項目擴展的時候，就會陷入循環依賴的困境（雞和蛋，誰先有？）。如果模板在其它進行聲明，例如在組織級別，那么Foobar-Travels目錄中的project.xml可以用于構建EAR，但是該文件就再也無法作為子項目的模板使用了。
Listing 13 shows the project.xml for the ear project. In the listing, you will not see every library on which the ear is dependent upon, just a few relevant ones that need some explanation.
表13給出了ear項目的project.xml。在此表中，并沒有列出ear項目所依賴的所有包，這里僅列出了需要解釋的相關內容。
Listing 13 project.xml for the ear project
表13 ear項目的project.xml
01 <project>
02 <extend>${basedir}/../project.xml</extend>
03 <id>foobar-travels</id>
04 <name>Foobar EAR</name>
05 <description>Sample EAR project.</description>
06 <shortDescription>Foobar EAR project</shortDescription>
07 <dependencies>
08 <dependency>
09 <groupId>j2ee</groupId>
10 <artifactId>j2ee</artifactId>
11 <version>1.3.1</version>
12 </dependency>
13 <dependency>
14 <groupId>xerces</groupId>
15 <artifactId>xerces</artifactId>
16 <version>1.4.4</version>
17 <properties>
18 <ear.bundle>true</ear.bundle>
19 </properties>
20 </dependency>
21 <dependency>
22 <groupId>${pom.groupId}</groupId>
23 <artifactId>reservationejb</artifactId>
24 <version>${pom.currentVersion}</version>
25 <type>ejb</type>
26 <properties>
27 <ear.bundle>true</ear.bundle>
28 </properties>
29 </dependency>
30 <dependency>
31 <groupId>${pom.groupId}</groupId>
32 <artifactId>foobar-web</artifactId>
33 <version>${pom.currentVersion}</version>
34 <type>war</type>
35 <properties>
36 <ear.bundle>true</ear.bundle>
37 <ear.appxml.ear.context-root>
38 foobar-online
39 </ear.appxml.ear.context-root>
40 </properties>
41 </dependency>
42 </dependencies>
43 </project>
- Line 25 Type = ejb indicates that this is a ejb jar, This is set in application.xml
- Line 34 Type = war indicates that this is a war, This is set in application.xml
- Lines 37-39 Sets the context root for the web application, This is set in application.xml .
- 第25行：“Type = ejb”表示這是ejb jar，這將在application.xml中設置。
- 第25行：“Type = war”表示這是war，這將在application.xml中設置。
- 第37－39行：為web應用設置context-root，這將在application.xml中設置。
The first dependency that you will find is on J2EE itself. This library is not bundled since the container at runtime provides it. The second dependency is on the xerces xml library - a representative of the dependency library (including our very own services jar). Libraries such as these may not be provided by the application server and have to be bundled with the ear. Then comes the ejb jar itself. The type=ejb sets the application.xml appropriately. Similarly, the web application is bundled by specifying the dependency and type=war. The above project definition automatically creates application.xml for the ear. By using ear:install as the goal, the ear is also copied into the maven repository. The generated application.xml is shown in Listing 14. Obviously, setting the type has had its effect. Also note the web application context-root setting. The short description from the project.xml is used as the display name for the EAR. When Maven starts the execution of project.xml for the EAR it sees the dependencies and then proceeds to create the artifacts for the dependencies before creating the EAR itself.
你會發現它依賴的第一項內容是J2EE本身，由于容器會在運行的時候提供此包，所以無需將其打包。第二項內容是xerces xml包，它是依賴包的代表（譯者注：因為表13中僅列出了一部分內容，這里將xerces xml包做為代表列出）。由于應用服務器可能并不提供這樣的依賴包，所以必須將它打入到EAR中。隨后的是ejb jar，“type=ejb”將會使得其在application.xml中正確設置。同樣，Web程序也要打包到EAR中，并說明“type=war”。因為使用ear:install，所以EAR也會被拷貝到倉庫中。生成的Application.xml文件如表14所示。顯然前面的type的設置在application.xml中起到作用了。同時，請注意web application 的context-root的設置。project.xml中的short description部分將會被用作EAR顯示名。當Maven為EAR開始執行project.xml時，它將觀察其所依賴的各包，并在創建EAR包之前，逐一的生成各依賴包。
Listing 14 Generated application.xml
表14 生成的application.xml文件
<application>
<display-name>Foobar EAR project</display-name>
<module>
<java>xerces-logging-1.4.4.jar</java>
</module>
<module>
<ejb>reservationejb-2.0.jar</ejb>
</module>
<module>
<web>
<web-uri>foobar-web-2.0.war</web-uri>
<context-root>foobar-online</context-root>
</web>
</module>
</application>
We haven't looked at the maven.xml for the EAR project yet. It turns out to be quite trivial in that it just executes the ear:install goal.
我們還沒看過EAR項目的Maven.xml呢，它的內容很短小，只是執行ear:install goal。
<project default="foobar-dist">
<goal name="foobar-dist">
<attainGoal="ear:install"/>
</goal>
</project>
Another file that you need to provide is project.properties. By default auto-generation of application.xml is turned off. To force auto-generation, you can set the property in project.properties as follows，and place the file in the ear folder under Foobar-Travels directory.
此外，還需要提供一個project.properties文件。在默認情況下，是無法自動生成application.xml的，因此你需要在project.properties文件中如下設置屬性，才能強制自動生成application.xml，并將其存放到Foobar-Travels中的ear目錄下。
maven.ear.appxml.generate=true
Using the reactor（使用reactor）
We have covered all the files in building a J2EE project, except one. This file that we have been intentionally postponing till the end is the maven.xml that accompanies the master project template. In the last subsection on building EAR, I stated "When Maven starts the execution of project.xml for the EAR it sees the dependencies and then proceeds to create the artifacts for the dependencies before creating the EAR itself". I lied! This is not completely true. The project definition for EAR is just like any other project.xml. For every dependency stated in that file, it will search the maven repository for the appropriate jar file. What this means is that you will have to run maven individually from dependency library projects, ejb projects, web application projects and finally the ear project in that order to execute jar:install, ejb:install, war:install and ear:install respectively. Now, that can be too cumbersome if not impossible in a large project. Maven offers the reactor as a solution to this problem.
我們已將構建J2EE項目的所有內容基本講完了，最后還有一項內容，它就是我們故意延遲講述的和主項目模板一起的maven.xml文件。在構建EAR的最后一段，我是這樣講的“當Maven為EAR開始執行project.xml時，它將觀察其所依賴的各包，并在創建EAR包之前，逐一的生成各依賴包。”。哈，我剛撒謊了，這并不是真的。EAR的project.xml的定義和其他項目是一樣的。在project.xml中，只給出每一個依賴，然后maven將會在倉庫中搜索相應的jar包。這就意味著：你必須自己單獨的為每個子項目運行Maven，包括依賴包項目（services）、Ejb項目、Web項目、以及Ear項目。你必須在每個項目下分別運行jar:install, ejb:install, war:install and ear:install才能完成任務。如果在大的項目中也是如此，那就相當讓人麻煩了。Maven提供了reactor解決此問題。
Reactor is a tool for executing dependent multi-project builds. Given a set of project.xmls, the reactor determines the correct order of execution based on the dependencies listed in the respective project.xmls. More news: The reactor can be declared using Jelly scripts in the maven.xml file itself. This is what we will have in the maven.xml accompanying the master project template. The maven.xml in the Foobar-Travels folder (See Figure 3) is shown in Listing 15.
Reactor是一個執行“多項目依賴”構建的工具。當你給出一些project.xml文件時，reactor會根據各項目的project.xml中所聲明的依賴關系，決定它們執行的正確順序。另外，reactor可以使用Jelly腳本在maven.xml中編寫。這里我們在主項目模板的maven.xml文件中編寫reactor，Foobar-Travels目錄（參見圖3）中的maven.xml內容如表15所示：
Listing 15 maven.xml using the reactor
表15 使用reactor的maven.xml
<project default="foobar-buildall" xmlns:m="jelly:maven">
<goal name="foobar-buildall">
<m:reactor basedir="${basedir}"
includes="*/project.xml"
goals="foobar-dist"
banner="Building"
ignoreFailures="false"/>
</goal>
</project>
The foobar-buildall goal is written as a reactor. The script for foobar-buildall in Listing 15 translates to simple English as "Starting from the base directory from where maven is executed, go to every subfolder and execute the goal identified by foobar-dist in every project.xml and stop on failure". When you go to the base directory (Foobar-Travels) and type in the command maven (since foobar-buildall is the default goal), the reactor figures out the dependency by reading all the project.xmls in the subdirectories and creates the artifacts in the required order.
這里的foobar-buildall goal中使用了reactor。表15中的foobar-buildall這段腳本翻譯過來就是“從執行maven命令的根目錄開始，到每個擁有project.xml文件的子目錄下面執行名為‘foobar-dist’的goal，當遇到失敗時，則停止” 。當你在Foobar-Travels目錄下，敲入命令“maven”時（因為foobar-buildall已經被設為默認goal），reactor將會讀入子目錄中的所有project.xml文件，然后計算出他們的依賴關系，然后按照所需要的順序分別生成制品。
Conclusion（結論）
This article has explained how to use Maven effectively in a J2EE project instead of plain old Ant scripts and bring about some order and modularity to the otherwise chaotic world of build and deployment. Maven is something that you should consider when looking for options to build and deploy in your project. But I've have only scratched the surface of what constitutes Maven. I hope this article has given you the confidence to build your J2EE projects with Maven and sparked your curiosity to learn more about it.
本文講述了如何在J2EE項目中使用Maven，而不再使用簡舊的Ant。使用Maven使得項目的構建部署不再混亂不堪，整個過程更加有序化、模塊化。在你選擇“構建項目的途徑”的時候，Maven是一個相當值得考慮的方式。這里我僅討論了Maven的淺層內容，我希望這篇文章可以給你帶來在項目中使用Maven的信心，并激發你了解其更多的興趣。
About the Author（有關作者）
Srikanth Shenoy is a Technical Architect at Objectseek Inc. (http://www.objectseek.com). He specializes in the architecture, design, development, and deployment of large J2EE and EAI projects. He has helped clients in the manufacturing, logistics, and financial sectors to realize the Java's "write once, run anywhere" dream. He is a Sun Certified Enterprise Architect and co- author of the upcoming book Practical Guide to J2EE Web Projects. You can reach him at srikanth@srikanth.org.
Srikanth Shenoy是Objectseek( http://www.objectseek.com )公司的技術架構師。他主要專注于J2EE和EAI大項目的架構、設計、開發及部署工作。他已經幫助了許多制造業、后勤業、金融業的顧客，幫助他們實現java的“一次編寫，到處執行”的夢想。他還是Sun的Certified Enterprise Architect，以及將要面世的《Practical Guide to J2EE Web Projects》的合著者。
Resources（資源）
- Download the Accompanying Source Code for this article.
- 請下載本篇文章的源代碼。
Written by Srikanth Shenoy November 2003
Translated by jinfeng wang 2005年三月
原文地址：http://www.theserverside.com/articles/article.tss?l=MavenMagic
本文的翻譯已經原作者同意，轉載請保持原文。如有問題和意見可以和原作者或我聯系。
Part 1: http://m.tkk7.com/jinfeng_wang/archive/2005/03/11/1956.html
Part 2: http://m.tkk7.com/jinfeng_wang/archive/2005/03/14/2074.html