Reference

If you don't know EasyAnt at all, give a glance at its features, the FAQ and the tutorials before digging into this reference documentation.

How does it work?

Since 0.6, easyant-core.jar is in charge of : This can be configured in a configuration file.

Then it uses the loadmodule task provided by easyant, which basically parses an Ivy file (module.ivy) and looks for instructions in the Ivy file for easyant (similar to the pom concept actually).

Finally easyant tries to import an optional file called module.ant in the user directory (the module to build). In the examples, there is no such file, but this would let the user customize the build with an Ant script if necessary.

EasyAnt instructions in module.ivy

A module.ivy looks like this 
<ea:build organisation="org.apache.easyant.buildtypes" module="build-std-java" revision="0.2">
        <ea:property name="run.main.classname" value="org.apache.easyant.example.Example"/>
        <ea:property name="target.artifacts" value="dist"/>
        <ea:plugin module="emma" revision="0.1"/>
</ea:build>
The idea is to have a very limited options of customizing the build in the Ivy file: settings properties, and telling which main build module should be imported. If you need more, you can use a module.ant file.

Let's try to understand how to use it.
'ea:build' tag is the main instruction. Type argument in easyant tag references a build type, which tells which build module should be imported (considered as an import), see below.
Example: 
<ea:build organisation="org.apache.easyant.buildtypes" module="build-std-java" revision="0.2">
You can also have property definition, as you would have in an Ant script
Example: 
<ea:property name="target.artifacts" value="dist"/>
Usually build-type does the basic stuff. But sometimes we need something more (Source code management feature / code coverage etc...).
You can load several plugins using the plugin tag.
Example: 
<ea:plugin module="emma" revision="0.1"/>
In this example emma module is loaded as a plugin(considered as an include).
As easyant proceeds with execution, all targets are imported in current project prefixed by the project name.
This means all targets included in emma module will be prefixed by org.apache.easyant.plugins#emma.
Example : 
org.apache.easyant.plugins#emma:emma generate emma covera report
As the name is not really "user-friendly" you can use an alias for the prefix using "as" attribute.
Example: 
<ea:plugin module="emma" revision="0.1" as="emma"/>
Doing this, all targets included in emma module will be prefixed by "emma"
Example : 
emma:emma generate emma coverage report

build plugins:

There is three types of build modules:

build types:

The main build script are build type (build-std-java in my previous example).

Build types are intended to provide a full build for a particular type of project (simple java, war, ear, ...). EasyAnt comes with a set of build types modules, but users could extend/replace these types as they want. Then in most cases they could simply define which build type to import for each module (either standard or custom), and that's pretty much all. Hence you usually import only one build type module at a time.
Module name Description
build-std-java a standard build for simple java modules, relying on standard phases, and providing compilation, execution and unit tests
build-webapp-java a standard build for webapp java modules, relying on standard phases, and providing compilation, execution and unit tests
build-std-scala a standard build for simple scala modules, relying on standard phases, and providing compilation, execution and unit tests

phases description:

Phases define an ordered set of build phases. Build phases are responsible for the build choreography at macro level. They are inspired by the same concept in Maven. In practice they are very similar to Ant targets, except that their dependencies can be defined by the dependency target using a syntax like this:
<target name="xxx" phase="yyy" />
This basically adds the target "xxx" to the list of dependencies of the phase "yyy".
Usually you use only one phases definition build module.
Module name Description
phases-std describes the standard phases of a build. These phase are directly inspired by maven 2 standard phases.
See Understanding phases to have more informations on phases.

Plugins

Build plugins are there to actually define each block of the build system. They interact with each other by relying on the file system and properties (for instance run-java expect java classes to be in directory pointed by ${target.main.classes}). For the whole build choreography they rely on phases. Each build plugin define the expected "parameters" (i.e. the expected properties, paths and phases) by using a parameter task like this:
<ea:parameter property="src.main.java" required="true" description="directory where sources to be compiled are" />
This is intended to be used both for validation and documentation, ATM only basic validation is performed.