Hani has written up "12 paths to build.xml nirvana". Have you struggled with options for setting up your build environment? Hani thinks that you can follow the path, and you will reach a Good Place. Or is there some sarcasm :) Do you agree with these anti-patterns?

Blog Content

1. Always provide shell launchers for ant. A standalone build.xml is simply too demanding for developers, who are used to luxuries like build.bat and build.sh. Nothing says 'we care about your platform' like shell script launchers.

2. While you're writing those launchers, make sure you provide specialized ones so users can very easy call various build targets. Build.sh looks naked and sad without its childhood friends, make.sh, compile.sh, docs.sh, and run.sh.

3. Never place your build.xml file in your top level directory. The deeper in it is, the more likely it is that people will actually look at your stuff in a hopeless effort to find said file.

4. Never allow for people to customize the build process. Sourcing an external properties file is just cause for confusion and trauma.

5. If you do want customization, then force users to define env vars. Since every user's environment is unique and specific, why not demand and expect them to define 12 *_HOME type variables first? That way when they do get the build going, they'll feel it's like a personal customized version that is tailored for their own needs and nobody else's.

6. Never rely on -projecthelp. The default ant target should do nothing but spit out a few pages of useless info explaining all the available targets. Yes, ant does allow for this via the -projecthelp switch, but that assumes users know when they need help. It is obvious to you, almighty developer, than unless they explicitly ask for something else, they want help.

7. Your default target should try to surprise and amuse users. Why have a target that just builds your project when instead you can have it build a whole distribution? Sure, builders are those who might well poke about the source and want quick builds via ant, but screw them. A whole distribution just looks so much more professional.

8. Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where.

9. Never ship dependent jars. As any true maven asshat knows, jars should be delivered over the network from a central repository. This way you can automatically weed out those pesky enterprise users behind restrictive firewalls who are in all likelihood violently opposed to opensores anyway. Make liberal use of the get task, it's there for a reason you know.

10. Ensure a fresh start! Every target should depend on the clean target. This way you can be sure that the user will not have any problems with left over cruft from an old build. Sure, their build rate will slow down by a few orders of magnitude, but it's better to be safe than sorry.

11. build.xml should be your gateway to everything. Don't be fooled by its name, you can and should use it to run your apps too. Why bother with pesky manifests and cumbersome jar files? They're from the evil un-free empire of Sun, so you must shun them. Instead, make liberal use of the java task in ant. Real build.xml love will shine through the next time you type ant run.

12. Consolidation is for the weak. A single buildfile basically screams out 'I'm a girl and like bunnies and wear pink fluffy dresses'. If you're going for a more manly effect, then split your build.xml files into as many pieces as possible. Extra points for bragging about reusability and employing cunning task obfuscation. The casual user must never be able to figure out what is actually going on, or they'll get funny ideas that they could have done it themselves.

View the blog entry: 12 paths to build.xml nirvana

That was funny in parts, but a bit too close for comfort in others. Any ideas on where I can find patterns and anti-patterns for build processes

Shamir,

Check the Elements of Style article in the Apache Wiki: http://nagoya.apache.org/wiki/apachewiki.cgi?TheElementsOfAntStyle

Cheers,
-Stefan

Hi Shamir,

The book Jakarta Pitfalls (http://www.amazon.com/exec/obidos/tg/detail/-/0471449156/qid=1067725810/sr=1-1/ref=sr_1_1/104-5839163-1796741?v=glance&s=books on amazaon) has a whole chapter dedicated to Ant antipatterns. The book presents the way people hose themselves with ant as well as refactorings to make it better.

In this blog entry I also posted pointers to a presentation I did that included content from the book.

http://bill.dudney.net/roller/page/bill/20030917#jakarta_pitfalls_real_world_jsf

BTW: I'm one of the co-authors, so I'm a bit biased :-)

The Elements of Ant Style refered to a couple of posts back is really good for positive info about doing Ant correctly.

TTFn,

-bd-
http://bill.dudney.net/roller/page/bill

FIRST POST!

Is TSS this bad now? Random Joes copying blog content?

I'm truly hurt. I'd never copy content that wasn't explicitly requested for copying.

Actually, this is pretty cool stuff. The build process is often overlooked, and it was worth a chuckle. Who are you to criticize (ligitimate question)?

Best,

John C. Dale

My company is using CVS, TortoiseCVS, and Ant 1.5.4

We wrote a custom Ant build file for tagging, for creating tagdiffs, and
for generating a daily CVS change log.

http://ant.apache.org/manual/CoreTasks/cvs.html

http://ant.apache.org/manual/CoreTasks/cvstagdiff.html

http://ant.apache.org/manual/CoreTasks/changelog.html

In CVS, we have an "exploded EAR" directory structure for all of our EAR files.

http://edocs.bea.com/wls/docs81/deployment/overview.html

Do most developers use exploded EAR files?

I'd like to share some practical suggestions.

Avoid copying files into target directory and then pack them all from there into jar, war or ear file. Use zipfileset instead. That improves build time significantly. So, I had to rewrite Maven goals, just because of that.

There are not much sence to have exploded jar or ear files in CVS. Lot of descriptors can be generated and I do belive that they must be generated, i.e. by XDoclet.

It is good to have project structure for war file close to the exploded format, so it can be deployed in-place.

If you have a lot of dependencies or common shared components, then it is definetely time to look on Maven (even if you have to rewrite predefined goals, this tool have loot of goodnes for project versioning and dependeny management, besides all those fansy things about web sites and reporting).

>
> Avoid copying files into target directory and then pack them all from there into jar, war or ear file. Use zipfileset instead. That improves build time significantly. So, I had to rewrite Maven goals, just because of that.
>
> There are not much sence to have exploded jar or ear files in CVS. Lot of >descriptors can be generated and I do belive that they must be generated, i.e. >by XDoclet.

Exectly those are two reasons why Maven does things as it does:

a) If you want to be even quicker forget about creating wars, ears archives. Exploded ears, wars are the way to go if you want to test and build quickly.
b) Maven builds wars, ears in 2 distinct steps so tools like XDoclet can easly be plugged into the workflow and for example generated descriptors into well defined places.

So approch which gives you both: speed and flexibility (in the sense of workflow) is supported by Maven.

Surly b) does not mean that zipfileset could not be used.

Michal

Michal,

That 2 step build used by maven will cause you several extra _hours_ when rebuilding a release build with lot of the dependencies. I'm not speculating, that was the case for one of the cases I've refactored.

I ran in perfomance problems once with jar. What really helps is to assign enough minimum heap size (if I recall you should try the size of the target jar file + some margin). Otherwize the jar task will spend a lot of time reallocating heap over and over.

I am starting a new project and would like to add an ability to update version information (similar to JBoss and their Version class). Can someone point me to some examples on the method? Also, is there a way to maintain the version level in the Java file itself?

TIA

-Pete

If you're using CVS, then you can take advantage of keyword substitution, by adding a static variable.

private static final String VERSION = "$Revision$";

Section 12 of the listed antipatterns made my cheeks blush; I have separated the build.xml into multiple xml-files with descriptive names like "ejb_build.xml" or "backend_build.xml", and included those into the main build.xml (using xml &entity).

I though it was a good practice (almost a pattern...) to split the build.xml file since it allows me to easily find the correct part which to edit as well as .. Any thoughts? All files reside at the same directory which contains only build.xml and related files.

<Janne>I though it was a good practice (almost a pattern...) to split the build.xml file since it allows me to easily find the correct part which to edit as well as .. Any thoughts? All files reside at the same directory which contains only build.xml and related files.</Janne>

This is perhaps what Hani is fighting against in his own colorful way. This is a good practice (it also helps in source control developers updating separate build files do not affect each other), but only were appropriate and done in a proper structured way. A good build file structure is more important than many small haphazard files. I Have seen projects where build files were deeply nested in a strange way that was very hard to follow.

You are right.

The point is that you shouldn't split one build file over multiple files.

I use a structure such as:

application
    build.xml <-- builds the entire application
    src
        com...
    test
        com...

    component_one
        build.xml <-- builds component one in it's entirity
        src
             com...
        test
             com...

    component_two
        build.xml <-- builds component two in it's entirity
        src
             com...
        test
             com...

Then I can execute, for example, build.xml for the component_two component, which builds only that component. The build.xml file for the application doesn't know exactly what the components are, and doesnt care. It's job is to orchestrate the build processes for the sub-components by calling any scripts in the sub-component's directory, and obtaining the output (jar).

This means that I retain fine-grained control over the build process, and every script only knows about what it is to build, therefore promoting loose coupling.

There is no reason not to employ techniques that work with Java code etc in build scripts!

Bash has a powerfull feature called programmable completion. From the command prompt you can write "ant ", then press tab twice and bash will print out a list of all the targets in build.xml. Or you can write "ant co", hit tab twice and bash will print out targets starting with co if there are any.

Of course programmable completion works for many other programs as well.
Take a look at the documentation here: http://www.caliban.org/bash/index.shtml.

One of the core task done using ant build process is to compile Java Programs. I have often seen that programmers compile all of their Java Programs at one Shot (Even if all the java files are not dependent!!!!). In my present project we compile around 3000 java files at one shot. It would be nicer to group the java files as per the modules (Taking care that no java files have their dependency outsite their modules)....and then compile the modules seperately. This often prevents the famous "out of memory" errors in the ant build.

A gold nugget from IBM developerworks (http://www-106.ibm.com/developerworks/xml/library/x-antxsl/)

A one line addition to make your build script readable!
Do yourself a favor and check it out.

Add an XSLT declaration to the top (right after the <?xml ... ?>

<?xml-stylesheet type="text/xsl"
href="http://www-106.ibm.com/developerworks/xml/library/x-antxsl/examples/example2/ant2html.xsl"?>

and open it in your XSLT-supporting browser (e.g. Internet Explorer).
Of course, if you like it, you should probably copy the stylesheet locally and modify it to yor tastes.

BTW, the first part of the article is (IMHO) not very usable - it talks about generating ant scripts through XSLT.

you can also use ant2dot (http://www.okchicken.com/~pvdb/ant2dot) to visualise the build script.

eddie

you can also use ant2dot (http://www.okchicken.com/~pvdb/ant2dot) to visualise the build script.

Following up on Eddie's posting: the ant2dot.xsl stylesheet for visualizing Ant targets and their dependencies has been moved to sourceforge.net: http://ant2dot.sourceforge.net/

Peter

This is such a lame article.

This is a nice collection of worst practices. I'm wondering what was the reason for posting this mmmm... stuff here at TSS.