What do "Real World" Ant Scripts Look Like?
First and foremost, thank you to those who commented in the [url=http://forums.thedailywtf.com/forums/p/11147/193853.aspx]"Real World" Java Thread[/url] -- good stuff. It was very helpful info.
So my follow-up is... what do "real world" Ant scripts look like for enterprise/information systems? Again, the blogosphere is abuzz with all the awesome Ant, Ant-Optional, and 3rd-party tasks... but how many of these are used? The open source Java projects I could find ranged from a simple "clean, javac, copy" script to things so unimaginably complex (nested build files, etc) that I had no way of following it. I'd immagine most "corporate" scripts are simple but also involve an svn task or something.
What do Ant scripts look like and do in your environment and places you have worked? Who wrote the scripts in the first place? Is it pretty much like copy/paste maintenance now? If possible, I'd love to see your Ant scripts...
I'd say ours is roughly equivalent in complexity to a makefile. There's a target that builds the jar/war/etc. There's some stuff to convert generic @some.important.thing@ type tags in code and config files to specific values (could be the connect info for a database, or paths that could be specific to a particular development/test/production environment, etc). Then there's code to deploy to the actual server. There's a task to rebuild the database schema and load in some test data, and another task to run unit tests.
It's not too fancy IMHO, but it works well enough. The maintenance occurs when we need to add a jar, or if we need to change something that's used to communicate with some other app server. Each user (plus our test and production environments) have a config file that's specified when you run ant (e.g., ant -propertyfile config/users/spectateswamp).
Only real Ant scripts I've run into with my work were to do with J2ME (micro edition, mobile phone basically) applications, and they were above-average complexity because we used the to create multiple builds of the application for different devices with different resources compiled in. They basically copy-pasted a pile of stuff to temp folders piecing together all the things needed for that device, ran some preprocessor directives and compiled it. There was some extra stuff like signing and FTP'ing the output but that was rarely used. As far as who wrote them I'm not entirely sure, they were there before I arrived and I never worked on enough stuff that used them to bother finding out. I do know they remain almost entirely unchanged since I showed up - they fill a specific role and they do it well so they're left alone (If they needed editing I'm pretty sure nobody would know how without doing some research - they were made to work then forgotten about).
We also use some nAnt scripts (basically .NET Ant scripts) which mostly deal with deploying sites to different servers with different web.config files for each environment with all the paths and access rights to deploy all stored in a cenral database and deploys controlled by webservices. I actually wrote most those myself to add some structure and try to replace the old deploy methodology (Copy/paste to live webserver via remote desktop straight from the developer's PC, I got scared every time a site got deployed though luckily very few actually went wrong =P).
I would say there is no typical "Real World" Ant script, it highly depends on what you need it to do.
Our Ant scripts aren't complex, it's basically: clean, compile, test, package, publish.
The main complexity comes down to us building two different 'versions' of a product from one build file.
I think most Ant scripts evolve as a project evolves, some places I've worked at have had templates but everything else I've worked on has just expanded when it's needed to. One of the things I like about ant is its flexibility, although unfortunately that leads to a lot of diversity in the way people use it.
One tool which I haven't used in a while but which is probably a bit more structured than Ant is Maven, which seems to be gaining popularity.
In my experience it is copy/paste maintenence and a big ball of spaghetti. A lot of reduntant code, bugs and inefficient stuff. Ant is a strange mix between declarative and procedural: hard to instruct explicitly but also lacking more than fairly simple declarative tasks. It does a good (fast) job with the old "clean, javac, copy", but you have to jump through some serious hoops to do complex builds. Try deciding if you should run tests or not (based on recompile etc), instrumenting, conditional builds etc. Macrodefs are ok, but have some serious drawbacks (no if/unless, no conditional properties). Also try doing some foreach-style stuff, i.e if you need several different dists. You end up with a gazillion macrodefs or antcalls and a horrible mess. Hierarchical builds are ok with the "new" subant, but still quite crude compared to some other systems.
I agree that making an ant script is quite similar to makefiles in terms of effort. This is quite significant, and somewhat encourages monolithic projects. I always start out with maven, and if I feel like I need serious speedup or some really strange req which don't fit into maven (even as a maven ant task), I build an ant script which fits the structure of the maven project.You can use 'maven ant:ant' to generate a start script for you. One thing to look out for with maven (and Ivy for that matter) is that declarative deps can be a major problem if you don't have control over the dependencies. Try to set up a local repo for the company/project. You can even create a repo in a source control dir if you are branching a lot (different branch builds overwrite each other in the repo if they have the same version number, you use the release plugin (release:branch) to avoid this if the repo is central).