Technically Phing uses a layered model to perform its actions. The following section briefly describes the layers used by Phing. If you're only a user who does not want to extend Phing or are not interested in the interior of Phing you can safely skip this chapter.
The Init Layer sets up the working environment for Phing. It provides core services like the Logger, a Timer, a file I/O API and so forth. For the technical details on Init see the chapter about developing with Phing. Basically the Init Layer consists of various different file located in different places:
The exact files and techniques used for the init process are not discussed in this chapter. To get a brief idea simply browse the files mentioned above. More detailed insights to the matter are given in: [REF].
Phing needs to find some files and constants that are accessible throughout the system. First of all it determines the system environment variables that have to be set during the installation of Phing. See Setting up Phing for more information on setting up Phing. If this very essential variables can not be found or guessed the program terminates with a proper error message. We assume everything is set-up properly and the initialization of paths and constants went fine.
The system uses a generalized package support, similar to the Java package support to locate and include required source files. This package support must be set-up properly so Phing finds all the files it needs. The Init Layer does this for you given your environment variables are set properly.
To put it in a nutshell, the Init Layer
While the parts of the system layer might be useful for other applications, too, the Phing Layer provides you with several modules that only make sense within Phing. The modules in this layer use the first layer to throw exceptions, etc., so this one is on top of Init Layer.
First, the Phing Layer contains classes derived from some of those in Init Layer, like:
Second, the Phing Layer provides you with base classes for Projects and the "things" in projects: Targets, Tasks and Types. Phing always operates on one project that contains Targets, Tasks and Types.
Tasks are "pieces of code" that are executed. They are implemented as classes. See Extending Phing for details. Types are essentially the different type of variables that are available to be used within tasks. These types may be complex (filesets, etc.) or simply a wrapper for key/value pairs. Targets are "chunks of tasks and types" that have a unique name -- sorta like functions/methods.
Every project has a default target that is executed, if no target to execute is given to Phing, but you can call other targets from the command line, too. Targets may depend on each other, e.g. if Target A depends on Target B, Phing will execute B before A.
So, but how to define these Projects and their components? Well, the answer is: We define them within a build file. What format to chose? Because build files have a hierarchical structure -- Projects containing targets, containing tasks etc. -- they are written in XML.
These XML files have to be parsed. For that, the Phing Layer provides an XML parser that is give a list that maps tag names to classes. So, for example, ProjectParser knows, the <property> Tag and the information defined in it is handled by phing.tasks.system.PropertyTask.
For more information regarding the Parser and the parsing process and how to write your own files, please see Extending Phing.