Maven 3 + Eclipse / IntelliJ, both with their Maven plugins. This means the IDE invokes Maven transparently. Nexus as team-wide Maven repository which proxies remote repositories.

There is no need in hand-crafting Ant builds for most scenarios, and if necessary, there is a two-way integration from Maven to Ant (Ant plugin) and from Ant to Maven (exec task). We use Ant for integration builds which invoke Maven's build twice: once to build and deploy, and then to run the tests against the remote integration environment.

Maven gives you a standard project structure for free, so new developers can start straight away, and the dependency management means partial re-builds are easy. There is also a lot of community support. Sonar is a point in case - a great new quality metrics framework built for Maven projects. And it's free as well.

On a side note, IntelliJ seems to be somewhat more performant than Eclipse in terms of handling multiple Maven projects. We deal with this by only importing projects you're working on, the rest is resolved from our team-wide Nexus repository.

Maven is very easy to use as compared to ant. Maven has eclipse plug in too. We were using ant, when I came to know about Maven and started using it, I liked maven better. I will continue to use maven hence forth.

We use Maven exclusively for a lot of reasons: Productivity, Repeatability, Consistency, and Conventions.

Having been a long time ant user, I can tell you that Ant is very flexible for whatever you want to have happen in your build process. Having said that, in last ten or so years of software, I don't think I have needed that flexibility in only a handful of projects. There are only so many times I want to write an ant build script that will simply do basic compiling, run test, and package an archive.

With Maven, the basics come right out of the box with the build lifecycle. I don't have to worry about what fileset to include or exclude for my build at all. I just define the dependencies if any and I am done. Also, Maven has a plug-in based architecture similar to Ant Tasks, so it can be easily modified as well. There is tons of plug-ins that support any from code coverage to running a web project in an embedded Jetty or Tomcat instance.

I think one the biggest reasons why we switched to Maven is the eclipse plug-in that builds Eclipse projects based on the maven pom file. There is similar plug-ins for Intellij and Netbeans as well. This way we have been able to make sure all developers have a consistent build environment to work from.

I could go on and on, but I will stop there. Let me know if you have any more questions about how we use Maven.

We use maven. As for incremental builds, one of our guys has put together a set of reactors for Maven that allows for building all stale dependencies, all stale dependents and a host of others. This dramatically cut down on our build times. About 3/4 of our guys use Eclipse and the rest Intellij, with a couple diehard emacs-ers. Our source control is Perforce.
Intellij uses Maven directly for projects, so it's very convenient. We use Maven's sub-module capability, so we have multiple modules, where each produces an artifact that the other's can use as a dependency. We hope to pare down the large main module, so that the build 'track' any particular developer is working on, won't drag in but a few modules at build/test time.

We use Ant and Ant only. The entire process is controlled via Ant targets. All builds whether development, QA, beta, or production are done via the master Ant script. Pulls from source control is also done via the Ant script. The use of Ant and source control (we happen to use subversion) are our only requirements of developers. The QA, beta, and production targets are defined platforms, but development is not. Some developers use Windows, some linux, some OSX. Some use Eclipse, some Emacs, some vim, some BBEdit. We don't care, they are professional computer users, so we expect that they can make that choice themselves. But they must build product with Ant.