Automated build for ATG, Ant or Maven ??

If you are not working with ATG, then, this article will be a waste of time, this article is for those guys working - or in other words suffering - with ATG. The case is you want to automate the build of ATG projects which are not following most of the JEE standards, they are using their own methodology which is not bad, but somehow weird. This article is to discuss whether it is better to use Ant or Maven for the build process of ATG projects.
------------
You can read about Ant here and Maven here.
------------

Well, maven is great tool indeed and i pesonally like it, unlike Ant, maven has knowledge about the whole project and handles alot of work in a declarative way, you just tell maven to compile the project and it compiles it without any configuration, this is due to its knowledge about the project, on the other side, Ant only knows about the build process, you define targets using XML script and define their sequence of execution, each target in an Ant build script does not know about other targets, it executes what you tell it to execute and nothing more, for example; to compile a project using Ant you need to define a compile target and tell it the classpath to use and where to place the .class files. Orginially, Ant did not support any dependency management technique, however, now Ant have a powerfull extension named Ivy which eanbles Ant to resolve project dependcies using maven's way, however, this does not change the main Ant concept of separate targets who do not know anyhing about each other, ivy enables you to tell it what artifacts (jars) you want and is gets it from a repository and places it in a directory.

It is very clear that maven is more advanced, more smart than Ant, but, for ATG projects the story is somehow different, the minimum build process for JEE application is as follows:

1- Checkout code.
2- Compile.
3- Test.
4- Package and deploy.

Maven and Ant works the same for ATG projects for the first step. Starting from the second step we see that to work with maven you need to add your project's artifacts to a repository and configure maven to look up that repository. To package an ATG project - (step 4) - you need ATG to be installed on the build machine to assemble (package) the project, this indicates that the needed artifacts are surely on the same machine you are working on, so the need of a repository is vanished. Why defining a repository while i know that the needed jars are on the build machine for sure. Here, Ant is more flexible and logic to use, you will just define the place of the jars and that's it, you can do this with maven, but you will end up loosing the power of it.

That packaging step makes maven loose its leverage over the prject even more, as in ATG projects the packaging will be done by making maven execute a shell command to run the assembler which is not what maven understands. The generated EAR will be totally outside the scope of maven and to deploy it you will execute another shell command to copy it to the desired location and loosing again the deploy feature of maven. Here also, the build process shows to be more likely an Ant style build.

Testing ATG modules is the most painful, all ATG developers knows the amount of hassle to unit test ATG modules, it is not as direct as spring. In  this step neither Ant or Maven have power points over each other it is bad all along the way and to get it done you need a lot of workarounds related to ATG.

Although you can do it with Maven, Ant is a better fit here as it is designed to handle builds that need flexibility and do not follow the normal and well known build steps.