Jaffa's build tools are orientated arround adding key features to the Ant based automated build and deploy process. If you are not farmiliar with Ant (from Apache) we highly recommend taking a look at it, once you start using it, you'll wonder how you ever lived without it.

We have test all our scripts with the latest release of Ant, currently we have been using v1.5.1 and v1.5.3. Most of our scripts are also compatable with the earlier 1.4.1 build.

Available Build Tools

• Ant Scripts
• Fragment Merging
• Configuration Verifiers

Without going ito too much detail here, we have some killer ant scrtipts. To get started look at the one we have developed for the SampleApp. This starter one will build a complete web application and stop the server (Tomact!), deploy the app, and then start the server. If you are currently doing this manually, then we've probably just saved you over 30 mins every day!.

For the more sophicticated scripts you can look at the Jaffa scripts that do automated unit testing, and also the one that builds the httpunit test application, deploys it, then builds the httpunit test, and executes them.

What the fragment merger does, is take a given file, and see if that has any sections to tell the merger to look for a given file name profile in a give source tree.

It is expected that the start and end markers will be on comment lines (the comments will be relative to the file type // for java, # for properties, <!-- --> for XML). All code inside the comment markers will be replaced with the contents of the located files.

With this approach you can use the same file for input and output and run the merge multiple times, and it only replaces the varible content. This is the same process used by the pattern engine for maintaining customizations when reapplying a template.

Here is an example taken from ApplicationResources.properties, notice that the files this is looking for are called ApplicationResources.fragment. You can follow the //GEN-BEGIN: with any filename you want...

my.definition.1=before merge
# ApplicationResource Fragments //GEN-BEGIN:ApplicationResources.fragment
# //GEN-END:ApplicationResources.fragment
my.definition.2=after merge

Here is the task for the ant build that puts that file through the merger...

  <!-- ============================================================ -->
  <!-- Merge resource file                                          -->
  <!-- ============================================================ -->
  <target name="build-applicationResources">
    <copy file="${src.java}/ApplicationResources.properties" overwrite="true" todir="${dist.classes}"/>
    <java classname="org.jaffa.tools.build.ConfigFileUpdate" failonerror="true" fork="yes">
      <classpath path="${dist.classes}"/>
      <classpath refid="project.class.path"/>
      <arg value="ApplicationResources.properties"/>
      <arg value="${src.java}"/>
    </java>
  </target>

Merging Struts

We have found the most painful file to manage is struts-config.xml. Here is a basic version that can then pick up the specific details from each component folder (See the SampleApp for a full version of this).

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
          "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN"
          "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd">
<struts-config>
  <!-- ========== Form Bean Definitions =================================== -->
  <form-beans>
    <!-- Code Generated Form-Beans //GEN-BEGIN:StrutsConfigFormBean.xml -->
    <!-- //GEN-END:StrutsConfigFormBean.xml -->
  </form-beans>
  <!-- ========== Global Forward Definitions ============================== -->
  <global-forwards>
    <!-- Code Generated Global Forwards //GEN-BEGIN:StrutsConfigGlobalForward.xml -->
    <!-- //GEN-END:StrutsConfigGlobalForward.xml -->
    <!-- GlobalForward For The Lookup -->
    <forward   name="jaffa_lookup"                path="/jaffa/jsp/lookup.jsp"/>
    <!-- GlobalForward For Closing a Browser Window -->
    <forward   name="jaffa_closeBrowser"          path="/jaffa/jsp/closeBrowser.jsp"/>
  </global-forwards>
  <!-- ========== Action Mapping Definitions ============================== -->
  <action-mappings>
    <!-- Code Generated Actions //GEN-BEGIN:StrutsConfigAction.xml -->
    <!-- //GEN-END:StrutsConfigAction.xml -->
    <!-- Standard framework action for initializing and executing a component directly -->
    <action    path="/startComponent"
           type="org.jaffa.presentation.portlet.StartComponentAction">
    </action>
  </action-mappings>
</struts-config>

As most of the configuration data we use in Jaffa is based on XML, we do a great deal of runtime validation when loading these XML files. But not everything can be caught by a simple XML parse, so the following are additional features for the build process that can track down some of the potential problems before you even deploy the application.

Current Tools

• Duplicate Entries in the ApplicationResources.properties

  It is easy, but anoying to try and track down duplicate entries in the properties file, which normally result in you adding a label, and can't figure out why is not being picked up. Its normally because there is another entry in the properties file with the same key, and its being used instead. This when combined with merging all the labels in from various fragment files becomes more difficult because you always need to look at the merged file, but from that it is not clear where the actual source of that entry came from.

  So put the following task in you ant build and forget about this worry (until it causes the build to fail!)

  Example Ant Task

  <!-- ============================================================ --> <!-- Fail if duplicate keys in resource file --> <!-- ============================================================ --> <target name="validate-applicationResources"> <java classname="org.jaffa.tools.build.ValidatePropertiesFile" failonerror="true" fork="yes"> <classpath path="${dist.classes}"/> <classpath refid="project.class.path"/> <arg value="ApplicationResources.properties"/> </java> </target>

  Note: You could apply this to any properties file you want, in this case it is run on the merge file (hence the use of ${dist.classes} in the classpath)

Planned Tools

• Validating that a domain objects and its mapping file corralate to the pyhsical database in terms of tablename, fieldnames and datatypes. This can be a great asses as you tweak the database arround and possible forget to adjust the domain objects

• Validation the rules file. The rule.xml definitions refer to may domain object names and field names. It would be very easy to to refer to an invalid domain object, or field, which would result in no validation being applied to the object or field that you think it is.