The side effect of using the plugin is that I've been creating a whole bunch of disposable ATG modules. I'm fairly good at cranking these out now, but they're a hassle in bulk. So I wrote an ant script that creates ATG modules from a template. This will setup the EAR, WAR, and libs for you automatically. Click here for the file.
There's also some stuff in there about ATG versioned modules. I remember that there was a big annoying problem with CampaignOptimizer (otherwise known as A/B Testing). The details are in build.properties, but I don't remember precisely.
It's worth noting that versioned modules could have some advantages over regular modules for large scale enterprise builds. Notably, versioned modules can contain scripts that can automate deployment. Jason Goth goes over this in his presentation at the ATG Open. Relevant bits are as follows:
Versioned Modules
- Each versioned module contains an install script(s).
- The AACom module is a shell
Creates a dependency on the actual version of the site
The MANIFEST.MF contains just the following:
ATG-Required: AACom-1_36
Versioned modules allow completely automated deployments.
- The deployment script:
Copies the module files
Stops a portion of the servers
Runs the install script(s)
Starts Dynamo
Repeat process for remaining servers
- Written in Perl
The deployment script allows us to:
Upgrade without manual intervention
Avoid inconsistencies during the restart
Handle failed file transfers
- Dont start those servers
Rollback in case of failure
This is taken from the powerpoint slides. I have no idea exactly what he meant by much of this -- since ATG versioned modules are completely undocumented, much of what I already know is trial and error. Still, it's a good starting point.