I've been staring at quite a few Ant scripts lately, trying to find patterns that I can convert to Maven plugin configurations. The one thing that stands out from the general gunkiness of Ant scripts is that Ant - at least in its older versions - forces you to the extremes of abstraction for reuse.
Reuse in [legacy] Ant seems to be all about one of two approaches: using XML entities to "import" script snippets directly into your build, and calling Ant scripts from other Ant scripts. The former looks like the JSP @include directive, where the scripts importing these fragments must have a similar property structure, and such if you want the resulting script to be sane. The latter forces you to enumerate exactly which properties you will push down to the delegate script, and which ones you'll extract once it's done its thing. All of this makes for a true nightmare, if you need to trace and learn a build script. Properties magically appear in some places, and are defined with no apparent purpose in others. Oh, and the names of these properties? They get boiled down to the least-common-denominator of meaning, so their names no longer give any clear indication of what they're for or where they're defined/used.
I'd honestly forgotten about this aspect of Ant. I know some will argue that the newer versions allow macros, and thus avoid the need for magic/useless (depending on which way you look at them). But the hard fact is there are millions of lines of legacy Ant script out there, and much of it doesn't take full advantage of such elegant features. And, since I am doing a conversion here, why not convert to a system where the "macros" are binary artifacts maintained by a community, and where the entire configuration for the build is distilled into a single, easy-to-read file that's (at least, usually) unpolluted with build commands? Why use ad-hoc measures to stitch together builds that are in themselves patchwork quilts consisting of numerous factored-out build-script snippets with a system that seems to have no consistent, standard mechanism for accessing them in a distributed environment?
Many people have realized the consequences of such an environment. I've heard it called the Inner Platform Effect, where you now have an entire software platform for running builds, and it needs the same care and feeding - maintenance, testing, architecture - that your business software needs. This is where Maven shines, because it provides a standard access mechanism to plenty of binary, third-party plugins that are (at least to some extent) tested. This means that instead of importing or delegating to another script or macro in your build script, you supply only high-level configuration for prefabricated, standard, binary build steps to consume. No code, just configuration.
Looking at this stuff again, I'm beginning to realize how cushy my life in Maven world has been.
John is a former Engineer at Sonatype and is a software engineering expert specializing in build process / automation (particularly for Java software). His experience emphasizes engineering, not just software development; he interested in the process of making software reliable and supportable in ...
Explore All Posts by John CaseyTags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.
