If IDE Why use ANT

I have spent some time this morning using ANT, going over the syntax of the build.xml file, etc. What I can't figure out is if I am using an IDE like Sun One, NetBeans, Eclipse, whatever, then what advantage does ANT have for me?
Don't those IDE's basically build their own type of build file to use to build a project? ANT seems redundant in that case. Or even just a command line project builder. Which is fine and all, if you aren't using an IDE.

I use ant to do more than just build a project, I also use it to distribute it to different app servers. Ant makes it easy to build my project, then move it out to a Resin test server, something that is not built into eclipse.

I think it all depends on what you're intending to do. Certainly, SunOne Studio (or whatever they're calling Forte these days) can build all the classes in an entire project and JAR them up, but my understanding is Ant has the capability to do far more in the build process than just compiling and zipping...
If that's all you need a build process to do, though, then I would probably agree with your statement that there's not necessarily a reason to utilize Ant, and instead to stick with the IDE's tools.

The benefits for me: repeatable builds, low initial setup time, continous integration, features features features, XDoclet!!!, and IDE independence.
Repeatable Builds
All members of the team can run the same exact build script with the same exact reproducible result. If you rely on your IDE, then you are opening yourself up to inconsistencies among team members. Your setup could be slightly different to mine which could cause differences in our builds. Worse yet, these differences may be very difficult to find.
Low Initial Setup Time
Install Ant, get your source files and you are ready to build. With an IDE you must first install the IDE and then perform the lengthy process of creating and configuring your project(s). Hopefully not making any mistakes or forgetting to check any boxes during the project configuration.
Continous Integration
There are a variety of products available that will automate the building of your project using Ant. You can even go so far as scheduling builds to happen X times per day and post the results on a project page. Therefore, you can quickly tell if there are integration problems among team members that must be addressed. Try doing this with an IDE...
Features Features Features
Ant can do a ton of stuff that most IDEs can't. Such as FTP, email, jar signing, automated source checkout, run unit tests, run sql statements, telnet... the list goes on. If Ant can't do what you want then you can always write a custom task to do it. Besides many other products make use of Ant.
XDoclet!!!
No more writing deployment descriptors. No more writing EJB interfaces. Nuff said.
IDE Independence
Ant doesn't require an IDE. Therefore, builds may be run on a machine without an IDE installed and team members don't necessarily need to use the same IDE. Furthermore, when doing things like upgrading your IDE version, you will not have to worry about breaking your builds.
These are just a few of the things that I love about Ant. I really can't see doing development without it.

Originally posted by Chris Mathews:
The benefits for me: repeatable builds, low initial setup time, continous integration, features features features, XDoclet!!!, and IDE independence.
Repeatable Builds
All members of the team can run the same exact build script with the same exact reproducible result. If you rely on your IDE, then you are opening yourself up to inconsistencies among team members. Your setup could be slightly different to mine which could cause differences in our builds. Worse yet, these differences may be very difficult to find.
Low Initial Setup Time
Install Ant, get your source files and you are ready to build. With an IDE you must first install the IDE and then perform the lengthy process of creating and configuring your project(s). Hopefully not making any mistakes or forgetting to check any boxes during the project configuration.
Continous Integration
There are a variety of products available that will automate the building of your project using Ant. You can even go so far as scheduling builds to happen X times per day and post the results on a project page. Therefore, you can quickly tell if there are integration problems among team members that must be addressed. Try doing this with an IDE...
Features Features Features
Ant can do a ton of stuff that most IDEs can't. Such as FTP, email, jar signing, automated source checkout, run unit tests, run sql statements, telnet... the list goes on. If Ant can't do what you want then you can always write a custom task to do it. Besides many other products make use of Ant.
XDoclet!!!
No more writing deployment descriptors. No more writing EJB interfaces. Nuff said.
IDE Independence
Ant doesn't require an IDE. Therefore, builds may be run on a machine without an IDE installed and team members don't necessarily need to use the same IDE. Furthermore, when doing things like upgrading your IDE version, you will not have to worry about breaking your builds.
These are just a few of the things that I love about Ant. I really can't see doing development without it.

Awesome response Chris! If they ever decide to sale ANT, you would be the man to make it happen.

Ok, so has anyone been able to accumulate a list or find a resource that has all the available attributes that can be used in the default ANT build? Google finds thousands of ANT related articles and I have gone through a few of them and they all just hit and miss on the basic elements of ANT. And the books I have seen, I can't open the pages to see what kind of resource they provide.
Basically what I am looking for is some sort of ANT Cheat Sheet if you will for the default ANT build. So I can look up element tags, etc.
Thanks.

Originally posted by Gregg Bolinger:
Basically what I am looking for is some sort of ANT Cheat Sheet if you will for the default ANT build. So I can look up element tags, etc.

Check out the Ant Manual, in particular the section on Ant Tasks.

Originally posted by Chris Mathews:

Check out the Ant Manual, in particular the section on Ant Tasks.

Perfect again Chris. Missed that the first time through.
Thanks.

My Forte for Java (Sun One Studio) lets me use Ant with conventions. I use because I want the source files to be compiled in seperate locations make, jars or wars and thus perform simultanous jobs successively and repeatedly.

I appreciate everyone's response in this thread. I have an additional question to add though.
How many people use ANT in lieu of an IDE like Eclipse, Netbeans, etc.
I have never been a big fan of IDE's and thought that using ANT would be an alternative to using one.
I am a Text Pad, Command Prompt guy at heart. I feel I have more control and I feel ANT gives me that control that an IDE may hide.
Any comments?

Having been a developer for some 20+ years, it was not easy for me to give up my source editors either. But, IMHO, IDEs are the way to go because they do so much more for you. I currently use WSAD v4.0.3 and, for all its faults and limitations, it's still better than a text editor. I have also used WSAD v5 and it's significantly better than v4 but I currently report to brain-deficient managers who fail to understand that v5 would make me more productive
However, to me, an IDE and Ant are two different animals. I have created Ant scripts totalling several thousand lines to manage our nightly build to refresh, build, deploy, etc. our application. I just kick off the build when I leave in the evening and come in the next morning to find a new Enterprise Application installed on our Development server.
[ March 13, 2003: Message edited by: Jay Damon ]

I would recommend using the IDE to write code only, then use ANT for building, archiving, distributing, etc.
I think IDE's make me more efficient mostly because of the refactoring tools and code completion(for when you know the method name if you see it, but can't quite remember). But I would keep the build process out of the IDE.

I'm 100% with Chad here.
For me the most useful features an IDE provides are (not necessarily in that particular order) syntax highlighting, refactoring, code completion (not just method names but automagic imports etc.), auto-formatting and auto-compilation (so that I don't have to wait for 4 minutes for the complete build script to reach a missing semicolon).
I too prefer to separate the build process from the IDE -- mostly because the other developers' IDE and its configuration cannot necessarily be controlled centrally and the build process HAS to be controlled.
In addition there are some valuable things that all IDEs cannot do. For example, you can plug automated metrics, tests, coding convention checks -- you name it -- to the build process (or source control procedures for that matter).
[ March 13, 2003: Message edited by: Lasse Koskela ]

How many people use ANT in lieu of an IDE like Eclipse, Netbeans, etc.

Like Chad and Lasse, I don't see much intersection between the two.
I use an IDE for code development (OmniCore CodeGuide, which rocks!), and ant for build and deployment (and a whole host of other useful tasks).
Just because an IDE can dump class files somewhere doesn't necessarily make it a build tool.
bear
[ March 13, 2003: Message edited by: Bear Bibeault ]

I think I agree with everyone for the most part. But I think that something like JCreator is plenty an IDE for me. I don't think I need Eclipse, Netbeans, or anything quite that heavy. Code completion is a must, and syntax highlighting.
I just feel I have more control over things with a lighter IDE. But that is another thread all together.
Thanks for everyones input.
BTW - I am giving OmniCore CodeGuide a try. I like that they have it ported to linux and mac as well.
Thanks for the link.

Personally, I don't think I could live without the Refactoring capabilities of many modern IDEs. In this capacity, nothing comes close to touching IDEA. I could do the Refactorings by hand... but why?
I do like to have a decent text editor around for quick changes. UltraEdit is my current favorite. I also tend to do most of my JSP work within text editors since it shouldn't contain much Java code anyways.
To each their own... for me I don't believe I could be nearly as efficient using a standard text editor.

I do sometimes find that a "heavyweight" IDE conflicts with Ant.
For example: I occasionally make use of Ant's "filter" task, to replace tokens in some of my source files with the appropriate values from a configuration file. I also use conditional targets to build with alternate versions of source files depending on the configuration of the destination. If I load the project into Eclipse, it can't help but complain about syntax errors when it encounters the substitution tokens, and it also complains about duplicate classes when it encounters the slterantive source files.
A simple Java-aware editor such as TextPad has no such complaints. It doesn't care, and lets me do my job.

It seems that many people like using an IDE because of the productivity gains, but at the same time realize the benefits of Ant that Chris mentions. It would be useful to have repeatable automated builds independent of a particular IDE, and have access to all the smarts that modern IDEs have.
Actually, this is precisely what we are working on for NetBeans 4.0. NetBeans 4.0 will have a new project system, which will not use any proprietary build infrastructure - it will use Ant natively. When you create a project in NetBeans 4.0 (this can be a J2SE project or a Web project), the IDE will automatically create and maintain an Ant script for you. No explicit export or synchonization, it "just works". If you have some special build requirements that the IDE does not count with (like XDoclet), you can tweak and enhance the generated build script by hand.
If this makes you interested in NetBeans 4.0, you can download and try out current development builds at
http://www.netbeans.org/downloads/ide/development.html
Cheers
Petr Jiricka, Sun Microsystems

Originally posted by Petr Jiricka:
If you have some special build requirements that the IDE does not count with (like XDoclet), you can tweak and enhance the generated build script by hand.

Petr, how will NetBeans handle synchronization after the generated build script has been touched manually? Will it just "leave it alone" or try to "merge" stuff in?

Originally posted by Frank Carver:
[QB]I do sometimes find that a "heavyweight" IDE conflicts with Ant.
For example: I occasionally make use of Ant's "filter" task, to replace tokens in some of my source files with the appropriate values from a configuration file. I also use conditional targets to build with alternate versions of source files depending on the configuration of the destination. If I load the project into Eclipse, it can't help but complain about syntax errors when it encounters the substitution tokens, and it also complains about duplicate classes when it encounters the slterantive source files.

If you do it right, it can work like a charm, though. Here is how we do it:
Give your template an extension other than .java (.src, .template - whatever). That way, Eclipse doesn't complain about syntax errors. Let Ant generate the .java file from it.
If you use Eclipse 3.0 Mx, add an Ant Builder to your project, that runs the appropriate Ant target before the Java Builder. Configure it so that it runs on all types of builds and depends on the template file (and optionally any other resources involved, for example properties files).
Now, every time you change the template file, Eclipse automagically calls the Ant target to regenerate the java class from it and then recompiles the project. Works equally well with JAXB, RMIC etc.

Petr, how will NetBeans handle synchronization after the generated build script has been touched manually? Will it just "leave it alone" or try to "merge" stuff in?

There will in fact be two build scripts, build.xml and build-impl.xml. build.xml is generated by the IDE just once when a project is created. This script delegates to build-impl.xml, which is regenerated by the IDE whenever the user changes a project option that affects building. The user should not touch build-impl.xml, but build.xml can be freely edited by the user (as long as the user preserves the delegation logic).

I also found Ant not quite useful, especially when sources need to be combined from multiple sources and depend on version JDK. So, I wrote my own tool and name it Bee. It solves all my problems.

Originally posted by Ilja Preuss:

If you do it right, it can work like a charm, though. Here is how we do it:
Give your template an extension other than .java (.src, .template - whatever). That way, Eclipse doesn't complain about syntax errors. Let Ant generate the .java file from it.
If you use Eclipse 3.0 Mx, add an Ant Builder to your project, that runs the appropriate Ant target before the Java Builder. Configure it so that it runs on all types of builds and depends on the template file (and optionally any other resources involved, for example properties files).
Now, every time you change the template file, Eclipse automagically calls the Ant target to regenerate the java class from it and then recompiles the project. Works equally well with JAXB, RMIC etc.

Could you explain more abotu the ANT BUILDER in Eclipse 3?

I think an IDE and ANT compliment each other. Some IDE's like WSAD have ANT tasks that repeat all the IDE operations in headless mode and thus give you a consistent build and development environment.
However, even if IDE lock in is a fear, most developers have environments that do not match the "official build." This is the environment that maintains unfinished and untested code that is not ready. It is often recomended that developers test changes in a build environment after checking in. IDE's should be used in the untested case. Once the code is checked in, they can use build tools like ANT to test their changes with the shared build.

Originally posted by Fred Grott:
Could you explain more abotu the ANT BUILDER in Eclipse 3?

Certainly! What do you want to know?