Building and Deploying an EAR - Exploring the New Directory Structure
(Page 4 of 4 )
The previous chapter included only the webapp directory. If you change to the ch03/03a-ear directory, you’ll see that we’ve expanded to a webapp directory and a common directory.
We also expanded from one to three build.xml files. Each subdirectory has its own build.xml, and the master build file lives in the top-level directory. The goal is to keep each portion of the application as autonomous as possible. Granted, most of the application will depend on the common sub-project, but by providing individual Ant scripts you have the opportunity to build each portion of the project separately.
The common sub-project Take a moment to explore the common sub-project. It contains a single class—CarDTO. We have created a new package structure to store all DTOs—com.jbossatwork.dto.
You can build this sub-project by typingant in the common directory. It compiles theCarDTOclass and bundles it up into a JAR file. After you’ve built the sub-project, change to the build/distribution directory and typejar tvf common.jarto verify that theCarDTOclass is indeed stored in common.jar.
The webapp sub-project The only change to the webapp sub-project from the previous chapter is the removal of the CarDTO class. To accommodate this change, we now must import thecom.jbossatwork.dtopackage at the top ofControllerServlet.
We also have to change our build.xml script to include the common.jar in our class-path. Notice that the definition ofcommon.jar.diruses a relative path to step up one level from the basedir of thewebapp sub-project and down into thecommonsub-project’s output directory in Example 3-2.
Example 3-2. webapp build.xml
<property name="lib.dir" value="lib"/> <property name="compile.lib.dir" value="compile-lib"/>
<property name="common.jar.dir" value="../common/build/distribution"/>
<path id="compile.classpath">
<fileset dir="${compile.lib.dir}">
<include name="**/*.jar"/>
</fileset>
<fileset dir="${lib.dir}">
<include name="**/*.jar"/>
</fileset>
<fileset dir="${common.jar.dir}">
<include name="**/*.jar"/>
</fileset>
</path>
Introducing cross project dependencies like this is not without risk. If you try to build the webapp sub-project before thecommon project is built, the build will fail because the dependent JAR won’t be present. Of course, most other sub-projects will have dependencies on thecommonproject by design—thecommonproject is meant to hold objects that will be shared across all tiers.
Having thewebapp sub-project rebuild thecommonproject every time could be an unnecessary step if thecommonproject changes infrequently. If we do not couple thewebappbuild process to thecommonbuild process,webapp developers can informally baseline thecommonproject by only rebuilding it when they make a conscious effort to do so.
Type ant in thewebapptop-level directory to build the WAR file. Change to build/distribution and typejar tvf webapp.warto see the contents. Verify thatCarDTOis no longer present in the WAR.
The master build
To ensure that each project gets built—in the proper order—we created a master build file. This file doesn’t actually compile any code; rather, it calls the appropriate build files of each sub-project in the proper order and then EARs up the results. Any failure of any sub-build will fail themasterbuild, so we can rest assured that a successfulmasterbuild is predicated on each individual build completing successfully.
To invoke a build script in another directory, we use the <ant> task. Here is what our compile target looks like in themasterbuild.xml file in Example 3-3.
Example 3-3. master build.xml
<target name="compile" description="Compiles all Java code">
<echo message="##### Building common #####" />
<ant dir="${common.dir}" target="all" >
<property name="jar.name" value="${common.jar.name}"/>
</ant>
<echo message="##### Building webapp #####" />
<ant dir="${webapp.dir}" target="all" >
<property name="war.name" value="${webapp.war.name}"/>
<property name="common.jar.dir" value="${basedir}/${common.jar.dir}"/>
</ant>
</target>
Notice that we also can override properties in the child build process. In both instances, we override the name of the JAR or WAR file specified in the child build. In the case of thewebapp build, we can no longer use the same relative path: your base directory is different now, so trying to move up a level and over doesn’t work. We pass thewebappbuild file a fully qualified path to the common output directory.
Please check back next week for the conclusion to this article.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article is excerpted from chapter 3 of the book JBoss at Work: A Practical Guide, written by Tom Marrs and Scott Davis (O'Reilly; ISBN: 0596007345). Check it out today at your favorite bookstore. Buy this book now.
|
|
