Sample custom Ant task

Back in December, I wrote about the steps I took to code a custom Ant task and drop it in my build toolkit. Today I am sharing my plugin project as a sample for anybody interested in trying this out on their own. Remember that this is a SAMPLE and NOT a supported solution. I provide it with no promises or guarantees whatsoever. It is JUST to get you started with your own custom coding. Note also that the sample uses an API that wasn’t available until, so you’re going to need to be pointing at the latest build toolkit if you want to get this guy to compile. Click here to download the sample.

Once you’ve imported the project and played with the source, you can follow the directions from the original post to export the plugin and drop it in your toolkit. Recall that the point of this task was to compute some changed files and load them to MVS. This task determines which files have changed by comparing the snapshot that is created for the build workspace when the build runs against another specified snapshot. All of the modified files in change sets that are in the build workspace snapshot but not in the other specified snapshot will be loaded to MVS. The snapshot that we compare against can be specified in several ways. The Ant task takes a “delta policy” that specifies which type of comparison to make.

A delta policy of “BUILD” tells the Ant task that we are specifying another build definition, and we will compare the running build’s snapshot against the snapshot from the last successful team run of the specified build definition. For example, if you are running a build in March, you would specify the January build to compare against. In this way, any files that were changed and “built” (loaded) in January will not be seen as changed or loaded in March. If no build definition is specified with the “BUILD” delta policy, we will load all of the files that have changed since the last time this build ran successfully. That is, if the March build is running with no comparison build definition specified, we would load all of the files that have changed in March since the last time the March build ran successfully.

A delta policy of “SNAPSHOT” tells the Ant task that we are specifying a specific other snapshot to compare against. You might use this if, for example, you need to load all of the files that have changed since the snapshot in Production.

A delta policy of “FULL” will load all of the programs in the build workspace.

The full solution is as follows:

  1. Create an Ant with Enterprise Extensions build definition.
  2. On the Properties tab, create a new property with value of true.  This prevents the file agent from loading out all of the files at the beginning of the build.
  3. On the Properties tab, create a new property deltaPolicy with value BUILD.
  4. On the Properties tab, create a new property deltaBuildDefinitionUUID with value equal to the UUID of the build you are comparing against to determine deltas.
  5. On the Jazz Source Control – z/OS tab, specify a Workspace, Load directory, and Data set prefix, business as usual.
  6. On the Ant with Enterprise Extensions tab, select “Use an existing build file” and specify a file such as deltaload.xml and include its complete path in USS on the build machine (e.g., “/u/ryehle/deltaload.xml”).
  7. Create your build script deltaload.xml on the host. It will look something like this:
<?xml version="1.0" encoding="UTF-8"?>
<project default="all" name="Delta load build">
   <description>Delta load build file</description>
   <taskdef name="loaddeltafiles" classname="net.jazz.ant.samples.tasks.LoadDeltaFiles"/>
   <target description="Load" name="load">
      <startBuildActivity autoComplete="true" buildResultUUID="${buildResultUUID}" label="Delta load" parentActivityId="${}" passwordFile="${passwordFile}" repositoryAddress="${repositoryAddress}" userId="${userId}"/>
     <loaddeltafiles deleteMetadata="false" generateListing="true" deltaPolicy="${deltaPolicy}" buildDefinitionUUID="${deltaBuildDefinitionUUID}" passwordFile="${passwordFile}" prefix="${teamz.scm.dataset.prefix}" repositoryAddress="${repositoryAddress}" userId="${userId}" workspaceUUID="${teamz.scm.workspaceUUID}" snapshotUUID="${snapshotUUID}" buildResultUUID="${buildResultUUID}" />
   <target depends="load" description="The Whole Thing" name="all"/>

I think that about covers it! Feel free to post back with questions in case I’ve missed a step here.

This entry was posted in Enterprise Extensions, Rational Team Concert, System z. Bookmark the permalink.

2 Responses to Sample custom Ant task

  1. Pingback: Automatically link rebuilt impacted files to a work item – Custom Ant Task | Jorge Díaz's Blog

  2. Pingback: Build Artifacts Publishing and Automated Build Output Management Using the Plain Java Client Libraries | rsjazz

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s