Good article! As usual, when reading something like this, I discovered tricks I didn't know, even though I've contributed optional task code to Ant.
One note: you do a nice job differentiating ant from make but I think though, that you miss the key differentiator between ant and IDE build systems. Yes, IDEs are not portable, but worse, they defeat attempts to provide complete build automation. Any time you have something such as a distribution which includes the output of many projects, you have to combine them. With an ant script (or, to be fair, a make script), there are excellent ways of doing that. They may require a little more learning curve but the benefits are well worth the cost. Some GUI IDEs may have provisions for nesting subprojects, but I've never seen one that gives you the level of control you need to do the job efficiently and with understanding. Their hooks for centralizing the output of subprojects for distribution are weak, at best. They are designed for quick compilation and debugging, not for distribution building. There are inevitably things you want to do that the IDE designer didn't think of; thus you can't do them easily if at all, and ease of use is the main purpose of IDEs. And since IDEs are based on the idea of ease of use, frequently they encourage laziness and compromise so that you do things the easy way the IDE allows instead of the "right" way you know would be best. Very well do I remember a "build engineer" at a commercial software vendor I used to work for whose build routine consisted of opening a series of MSVC++ projects in the Developer Studio and building each, then copying files to a central location from which he burned CDs. This error-prone process was a disaster and a big argument for truly automatable build systems like ant. -----Original Message----- From: Joseph Shelby [mailto:[EMAIL PROTECTED]] Sent: Fri 3/8/2002 3:32 PM To: Ant Users List Cc: Subject: new Ant article online I wrote an article showing some more advanced Ant uses, this time combining Ant with the JAXB early access release. It shows the use of Ant in compiling multiple source paths at the same time into the same destination; in this example it involves compiling both the user-written code and the JAXB generated code. http://www.onjava.com/pub/a/onjava/2002/03/06/jaxant1.html An upcoming followup will show some examples of writing Ant tasks, one which will go through your source path and come up with the packages that one needs to javadoc up so that the user doesn't need to keep that package listing up to date; the second will show how to establish a one-to-many dependency (ant tasks support one-to-one and many-to-one by default), so that the generated files of JAXB aren't re-generated except when the source XML descriptors are changed. These tasks show a more advanced example of using the Ant Path and Project classes. This followup should be out within the month. feedback welcome... Joe -- ---------------------------------------------------------------------- Joseph Shelby mailto:[EMAIL PROTECTED] 5809 Chase Commons Ct. #201 http://www.io.com/~acroyear Burke, VA 22015 (703) 323-7121 | 247-7868 Software Engineer, ISX Corporation, Arlington, VA "The people of England will permit anything...except cruelty to horses and a rise in the price of beer." -- Return of the Musketteers (1989) ---------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
