I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Caring about build files

01.07.2013
| 2618 views |
  • submit to reddit

Your build file is code, after all: written in a declarative language, with not much support for removing duplication, but nonetheless a center that accumulates complexity. Inside a build you may perform database migrations, creating archives, moving files between servers, and insert any administrative tasks from changing file permissions to restarting daemons.

When a build file is getting hundreds of lines long, what you can do to simplify it and why you should do it? In this article we'll see some examples of what you can usually improve in Phing build files, PHP's version of Ant.

Why should I care?

Strictly speaking, everything that is under version control in your project is a center, deem to accumulate logic over time; this is especially true for source files containing code of any kind.
XML is still code, and even if it's in theory declarative, you're usually listing a series of procedural steps (and writing conditionals with <if> tags).

So when you get to 500 lines of impenetrable XML, full of duplicated lines and commands, you can and should be able to refactor it to something more manageable.

Tool #1: custom tasks

Phing support custom tasks written in PHP code.

  • things that are easier done in PHP than with a jungle of <condition>, <loadfile>, <or>, <and> tasks: a way to shorten the code you need.
  • Repeated actions, since it's simpler to eliminate duplication inside PHP code than with the tools available in Ant and Phing.

For example, if you connect via SSH to a server during a build, it's usually always the same server: the machine you're deploying to. However, every time you issue a single command you're forced to write:

  <ssh username="${ssh.username}" pubkeyfile="${ssh.pubkeyfile}" privkeyfile="${ssh.privkeyfile}" host="${ssh.host}" port="${ssh.port}" command="cp file1.txt file2.txt" />


This is an harbinger of duplication. With a custom task that introduces a convention over the name of the properties that never change during a build, you can arrive to just:

 <sshondeploy command="cp file1.txt file2.txt" />

So how do you introduce a new task like <sshondeploy>? You can do it with custom PHP code, and with the <adhoc-task> task, whose only purpose is to define new tasks by evaluating the contained PHP code and binding them to an XML tag:

<adhoc-task name="sshondeploy"><![CDATA[
  class SSHOnDeploy extends Task
  {
  private $command;
   
  public function setCommand($command)
  {
    $this->command = $command;
  }

  public function main() {
    $task = $this->project->createTask('ssh');
    $task->setUsername($this->project->getProperty("ssh.username"));
    $task->setPubkeyfile($this->project->getProperty("ssh.pubkeyfile"));
    $task->setPrivkeyfile($this->project->getProperty("ssh.privkeyfile"));
    $task->setHost($this->project->getProperty("ssh.host"));
    $task->setPort($this->project->getProperty("ssh.port"));
    $task->setCommand($this->command);
    $task->perform();
    }
  }
]]></adhoc-task>

You can insert this <adhoc-task> wherever you want it to be evaluated, usually outside targets so that it's available anywhere.  

Tool #2: external build files

You can outsource tasks and targets for reuse between different projects, and it suffices to import them to make them available as if they were written inside the main build file. All the code in included build files will see the environment of the including one as its own, considering for example the same working directory and reading all properties: the documentation officially says that it's like if they were cut and paste inside the including file (much like PHP scripts do.)

Thus external build files can be the home of custom tasks, or even larger building blocks as targets. Write them like you would write a normal file, but without main targets (or even targets at all if you only want to extract tasks):

<project name="libraries" basedir=".">
  <adhoc-task name="mytask">...
</project>

Include them with the <import> task:

 <import file="library.xml" />

Tool #3: external custom tasks

Tasks can also be stored in PHP source files instead of inside XML code, which is a simpler way to check their syntax and to get highlighting. The good old PEAR namespace syntax is supported, and you can specify a class path to search for a file under this convention.

For example, this may be your libraries.xml file:

<project name="libraries" basedir=".">
  <path id="libraries_src">
  <pathelement dir="${phing.dir.libraries}/src/" />
  </path>
  <taskdef classname="Onebip_Phing_SSHOnDeploy" name="sshondeploy" classpathRef="libraries_src" />
</project>

The phing.dir.libraries is the folder of the imported build file when you <import> libraries.xml somewhere else.

This is the corresponding PHP file, src/Onebip/Phing/SSHOnDeploy.php:

<?php
class Onebip_Phing_SSHOnDeploy extends Task {
  // ... see earlier definition
}

Conclusion

Keep in mind that all the logic you codify with these tools is not reusable outside Phing: you may want to code external scripts for large tasks, that you can then <exec>. However, you can start to reduce the lines contained in your build.xml from today with veyr little overhead, first with custom tasks and then with external files.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)