Ant Scripts Support

Join built-in tasks for Ant

Commons attributes

Attribute Description Required
url The URL of the Join server you will use to realize the action represented by the custom Ant task. This URL should be the base URL of your frontend Join web application, e.g. something like http://myserver.mycomp.com:8080/join Yes
user The identifier of the user for connecting to Join remote services. This user should have the required permissions for performing the action represented by the custom Ant task. Exemple: user should have endorsed the joiner security role for logging a process status No, if join.security.user system property is defined
password The credentials of the user represented by the previous task attribute. No, if join.security.password system property is defined

Process status related tasks

Assign a status

The first Join built-in tasks for Ant -and the more frequently used one- is the LogStatusTask. You should use this task when you want to assign a specific status to the current process when you reach a defined point of your script execution. This is useful for keeping track of your process progress when important steps are done.

First, you have to define the custom logstatus task within a target of your script. Then, you can later use the <logstatus .../> task with correct attributes. Here is a typical usage example : 

<taskdef name="logstatus" classname="org.figure8.join.services.scripting.ant.tasks.LogStatusTask"/>
...
<logstatus process="assembly" ref="${assembly.key}" statusKey="assemblyOK"
          url="http://localhost:8080/join" user="foo" password="bar" />

The LogStatusTask has the specific following attributes :

Attribute Description Required
ref The reference of object to log status on. This is typically the key of the domain entity the process is related to. This may be the assembly key, the build key of the deployment identifier. Yes
process The name of the process the current script (or target) is dedicated to. This may be : assembly, build or deployment. Yes
statusKey The unique key identifying the status you want to assign to the entity being processed. This is one of the status you have defined when customizing your integration process. Yes

Assign a status on failure

The above LogStatusTask is useful when you reach a specified point into your script execution but what if you cannot reach that point because of a failure ?... Failures are unpredictable by nature so we need a way to assign a status on failure. That is exactly the goal of the ListenStatusTask, allowing you to assign a status to your process only when something goes wrong (kinda like a try/catch block !)

First, you have to define the custom listenstatus task within a target of your script. Then, you can later start the listening of failures that will assign a status before stop this listening on the end of your script step. Here is a typical usage example where the assemblyKO status will be assign to process if the directory denoted by ${src.dir} does not exists : 

<taskdef name="listenstatus" classname="org.figure8.join.services.scripting.ant.tasks.ListenStatusTask"/>
...
<listenstatus action="start" process="assembly" ref="${assembly.key}" statusKey="assemblyKO"
          url="http://localhost:8080/join" user="foo" password="bar" />
   <copy todir="${dest.dir}" failonerror="true">
      <fileset dir="${src.dir}" />
   <copy/>
<listenstatus action="stop" />

The ListenStatusTask has the specific following attributes :

Attribute Description Required
action The action to realize for build listener. This may be start or stop. Yes
ref The reference of object to log status on. This is typically the key of the domain entity the process is related to. This may be the assembly key, the build key of the deployment identifier. No, if action is set to stop
process The name of the process the current script (or target) is dedicated to. This may be : assembly, build or deployment. No, if action is set to stop
statusKey The unique key identifying the status you want to assign to the entity being processed. This is one of the status you have defined when customizing your integration process. No, if action is set to stop