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
-
Opinion: Writing a good build.xml (24 messages)
- Posted by: Dion Almaer
- Posted on: October 31 2003 14:07 EST
Threaded Messages (24)
- Anti-patterns for ant by Shamir K on October 31 2003 14:34 EST
- Re: Anti-patterns for ant by Stefan Kleineikenscheidt on November 01 2003 09:17 EST
- Anti-patterns for ant by Bill Dudney on November 01 2003 17:34 EST
- Opinion: Writing a good build.xml by Andreas Mueller on October 31 2003 14:46 EST
- Dumbass by Patrik Andersson on October 31 2003 15:32 EST
- Copying content by Joseph Ottinger on October 31 2003 15:34 EST
- Dumbass by John Dale on October 31 2003 15:49 EST
- Build and deployment by Sean Sullivan on October 31 2003 20:24 EST
- Have done Ant builds for last 4 companies I worked for by Eugen Kuleshov on October 31 2003 22:17 EST
-
Have done Ant builds for last 4 companies I worked for by Michal Maczka on November 01 2003 12:02 EST
- Have done Ant builds for last 4 companies I worked for by Eugen Kuleshov on November 01 2003 09:29 EST
- tip for use of jar/zip/ear: assign enough heap from the start by ac0dr on November 01 2003 06:29 EST
-
Have done Ant builds for last 4 companies I worked for by Michal Maczka on November 01 2003 12:02 EST
- Have done Ant builds for last 4 companies I worked for by Eugen Kuleshov on October 31 2003 22:17 EST
- Need some help with Ant by Pete Haidinyak on November 01 2003 02:19 EST
- Need some help with Ant by Joe Parks on November 01 2003 07:10 EST
- Multiple build files? by Janne Nyk?nen on November 01 2003 10:14 EST
- Multiple build files? by Tendayi on November 03 2003 05:42 EST
- Multiple build files? by Ben Hill on November 03 2003 06:26 EST
- Ant tips for bash users by Per Thomas Jahr on November 02 2003 09:54 EST
- Compiling Javs Programs thru Ant by Manjunath Rane on November 03 2003 00:16 EST
- Tip: Use XSLT stylesheet for viewing by Niels Ull Harremoes on November 03 2003 03:54 EST
- Tip: Use XSLT stylesheet for viewing by Eddie Chan on November 03 2003 08:24 EST
- Tip: Use XSLT stylesheet for viewing by Peter Vandenberk on March 26 2004 06:40 EST
- Tip: Use XSLT stylesheet for viewing by Eddie Chan on November 03 2003 08:24 EST
- Opinion: Writing a good build.xml by Edward Vrajmasu on November 03 2003 09:29 EST
- Opinion: Writing a good build.xml by Slava Imeshev on November 03 2003 18:07 EST
-
Anti-patterns for ant[ Go to top ]
- Posted by: Shamir K
- Posted on: October 31 2003 14:34 EST
- in response to Dion Almaer
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 -
Re: Anti-patterns for ant[ Go to top ]
- Posted by: Stefan Kleineikenscheidt
- Posted on: November 01 2003 09:17 EST
- in response to Shamir K
Shamir,
Check the Elements of Style article in the Apache Wiki: http://nagoya.apache.org/wiki/apachewiki.cgi?TheElementsOfAntStyle
Cheers,
-Stefan -
Anti-patterns for ant[ Go to top ]
- Posted by: Bill Dudney
- Posted on: November 01 2003 17:34 EST
- in response to Shamir K
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 -
Opinion: Writing a good build.xml[ Go to top ]
- Posted by: Andreas Mueller
- Posted on: October 31 2003 14:46 EST
- in response to Dion Almaer
FIRST POST! -
Dumbass[ Go to top ]
- Posted by: Patrik Andersson
- Posted on: October 31 2003 15:32 EST
- in response to Dion Almaer
Is TSS this bad now? Random Joes copying blog content? -
Copying content[ Go to top ]
- Posted by: Joseph Ottinger
- Posted on: October 31 2003 15:34 EST
- in response to Patrik Andersson
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. -
Dumbass[ Go to top ]
- Posted by: John Dale
- Posted on: October 31 2003 15:49 EST
- in response to Patrik Andersson
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 -
Build and deployment[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: October 31 2003 20:24 EST
- in response to Dion Almaer
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? -
Have done Ant builds for last 4 companies I worked for[ Go to top ]
- Posted by: Eugen Kuleshov
- Posted on: October 31 2003 22:17 EST
- in response to Sean Sullivan
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). -
Have done Ant builds for last 4 companies I worked for[ Go to top ]
- Posted by: Michal Maczka
- Posted on: November 01 2003 12:02 EST
- in response to Eugen Kuleshov
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.
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 -
Have done Ant builds for last 4 companies I worked for[ Go to top ]
- Posted by: Eugen Kuleshov
- Posted on: November 01 2003 21:29 EST
- in response to Michal Maczka
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. -
tip for use of jar/zip/ear: assign enough heap from the start[ Go to top ]
- Posted by: ac0dr
- Posted on: November 01 2003 18:29 EST
- in response to Eugen Kuleshov
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. -
Need some help with Ant[ Go to top ]
- Posted by: Pete Haidinyak
- Posted on: November 01 2003 02:19 EST
- in response to Dion Almaer
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 -
Need some help with Ant[ Go to top ]
- Posted by: Joe Parks
- Posted on: November 01 2003 07:10 EST
- in response to Pete Haidinyak
If you're using CVS, then you can take advantage of keyword substitution, by adding a static variable.
private static final String VERSION = "$Revision$"; -
Multiple build files?[ Go to top ]
- Posted by: Janne Nyk?nen
- Posted on: November 01 2003 10:14 EST
- in response to Dion Almaer
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. -
Multiple build files?[ Go to top ]
- Posted by: Tendayi
- Posted on: November 03 2003 05:42 EST
- in response to Janne Nyk?nen
<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. -
Multiple build files?[ Go to top ]
- Posted by: Ben Hill
- Posted on: November 03 2003 06:26 EST
- in response to Janne Nyk?nen
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! -
Ant tips for bash users[ Go to top ]
- Posted by: Per Thomas Jahr
- Posted on: November 02 2003 09:54 EST
- in response to Dion Almaer
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. -
Compiling Javs Programs thru Ant[ Go to top ]
- Posted by: Manjunath Rane
- Posted on: November 03 2003 00:16 EST
- in response to Per Thomas Jahr
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. -
Tip: Use XSLT stylesheet for viewing[ Go to top ]
- Posted by: Niels Ull Harremoes
- Posted on: November 03 2003 03:54 EST
- in response to Dion Almaer
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. -
Tip: Use XSLT stylesheet for viewing[ Go to top ]
- Posted by: Eddie Chan
- Posted on: November 03 2003 08:24 EST
- in response to Niels Ull Harremoes
you can also use ant2dot (http://www.okchicken.com/~pvdb/ant2dot) to visualise the build script.
eddie -
Tip: Use XSLT stylesheet for viewing[ Go to top ]
- Posted by: Peter Vandenberk
- Posted on: March 26 2004 18:40 EST
- in response to Eddie Chan
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 -
Opinion: Writing a good build.xml[ Go to top ]
- Posted by: Edward Vrajmasu
- Posted on: November 03 2003 09:29 EST
- in response to Dion Almaer
This is such a lame article. -
Opinion: Writing a good build.xml[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: November 03 2003 18:07 EST
- in response to Dion Almaer
This is a nice collection of worst practices. I'm wondering what was the reason for posting this mmmm... stuff here at TSS.