The participant who said, that both dependencies were packaged made a “mistake”. This behaviour happens, if you add a dependency, which have a newer transitive dependency than another dependency,that was in your project before. If you now perform a build, Maven puts the newer dependency in place but don’t delete the older one.
mvn clean helps in this case.

This behaviour affects only goals that package an application-archive, such as WAR or EAR. Dependencies are not packaged when building a JAR.

ANT is de-facto standard tool. It can be easily extended and customized to developer needs. The best example for this is Eclipse RCP projects. In addition, and this is the most important feature for me, it does not prescribe the way how I should organize my project. The currently used ANT framework makes a lot – it supports in-house version management (that is a little more sophisticated as Maven’s), starts different report generators and seamless integrates with an IDE. The advantage is the major modularity of ANT – the simplest ANT file contains of four lines, the complete framweork can reuse targets, split upon multiple parts, etc… According to the dependency resolution feature – there is Apache Ivy, which does the same as Maven but without Maven’s overhead.